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FXAMPLE FORM CLASS DEFINITIONS 

PUYER _ NAME: CLASS 1000 

RATING: FLOATING _ POINT CLASS II 
AGE: INTEGER CLASS 12 
LAST _ NAME: STRING „ 20 _ ASCII CLASS 10 
FIRST NAME: STRING _ 20 _ ASCII CLASS 1 0 



FIGURE 2 



PLAYER ADDRESS: CLASS 1001 

STREET; STRING 20 _ ASCII CLASS 1 0 
CITY: STRING 20 _ ASCII CUSS 1 0 
STATE: STRING . 20 _ ASCII CLASS 1 0 



FIGURE 3 



TOURNAMENT ENTRY: CUSS 1002 
TOURNAMENT NAME: STRING _ 20 _ ASCII CLASS 10 
PUYER: PUYER NAME CUSS 1000 
ADDRESS: PUYER „ ADDRESS CUSS 1001 



FIGURE 4 



STRING 20 _ ASCII: CUSS 1 0 
STRING 20 ASCII 

INTEGER: CLASS 12 
INTEGER 3 

FLOATING - POINT : CUSS 1 1 

FLOATING _ POINT _ 1/1 



FIGURE 5 
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INSTANCE OF FORM OF CLASS TOURNAMENT .ENTRY 
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FUNCTION TIB-PUBLISH-CREATE' 



430 

u 



3: 



SERVICE(S) STARTS SENDING 
DATA ON MANY DIFFERENT 
SUBJECTS INCLUDING SELECTED 
SUBJECT TO INFORMATION LAYER 
(TIB-INFO) AND INFORMATION 
LAYER CALLS SERVICE LAYER AND 
PASSES POINTER TO MESSAGE 



T 



432 

U 



SERVICE DISCIPLINE(S) DOES ANY 
NECESSARY FILTERING. ASSIGNS 
TIB CHANNEL NUMBERS AND 
PASSES POINTERS TO ALL 
MESSAGES TO DCC UBRARY OF 
COMMUNICATION LAYER AND 
SENDS ANY NECESSARY MESSAGE 
TO SUBSCRIBER PROCESSES 



434 



DCC UBRARY FUNCTION FIGURES 
OUT A WAY TO SEND THE 
MESSAGE POINTED TO BY THE 
POINTER FROM THE SERVICE 
DISCIPLINE. SELECTS A PROTOCOL 
ENGINE AND PUTS THE MESSAGE 
IN AN INTERPR00E88 TRANSFER 
TO PROTOCOL ENGINE 



436 

U 



PROTOCOL ENGINE DOES 
APPROPRIATE MESSAGE 
PROCESSING. WRITES PORT 
ADDRESS OF MACHINE ON WHICH 
SUBSCRIBING PROCESS IS 
RUNNING AND ASSIGNED TIB 
CHANNEL NUMBER INTO MESSAGE 
OR PACKET HEADERS OF 
MESSAGES BEING TRANSMITTED 
AND PERFORMS OTHER VALUE 
ADDED SERVICES 



438 



3. 



PROTOCOL ENGINE TAKES 
APPROPRIATE STEPS TO 
TRANSMIT MESSAGES 
RECEIVED FROM THE SERVICE 
DISCIPLINE TO PORT 
ADDRESS OF REQUESTING 
PROCESS ACCORDING TO 
REUABLE TRANSMISSION 
METHOD SELECTED BY 
SERVICE LAYER OF 
REQUESTING PROCESS OR BY 
DCC LIBRARY 



440 



TRANSPORT. NETWORK. DATA 
LINK AND PHYSICAL LAYERS 
OF NETWORK ARE INVOKED 
BY PROTOCOL ENGINE TO 
SEND MESSAGES TO PORT 
ADDRESS OF REQUESTING 
PROCESS 



442 

u 



NETWORK INTERFACE CARD 
PICKS UP EACH MESSAGE OFF 
THE NETWORK AND NOTIFIES 
OPERATING SYSTEM TRANS- 
PORT UYER PROTOCOL 
SOFTWARE THAT A MESSAGE 
HAS ARRIVED 



CONTD ON FIGURE 20 B 



FIGURE 20 A 
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FROM FIGURE 20 A 







1 


OPERATING SYSTEM TRANSPORT 
LAYER SOFTWARE CALLS 
PROTOCOL ENGINE OF DAEMON ON 
DISTRIBUTED COMMUNICATION 
UYER AND PASSES MESSAGE 
TO IT 


446 


TIB-INFO CALLBACK ROUTINE 
EXAMINES MESSAGE HEADER 
USING POINTER SUPPUEO BY 
THE SERVICE DISCIPLINE 
CALLBACK ROUTINE AND 
COMPARES THE TIB CHANNEL 
CODE TO THE SUBSCRIPTION 
TO VERIFY THAT THE MESSAGE 
IS ON THE CORRECT SUBJECT 


454 


i 




* ... — 




DAEMON REASSEMBLES PACKETS IF 
NECESSARY, DOES OTHER VALUE 
ADDED SERVICES IF APPLICABLE. 
FILTERS IF APPLICABLE AND 
CHECKS THE TIB CHANNEL DATA IN 
THE MESSAGE HEADER TO DETER- 
MINE IF ANY PROCESS RUNNING ON 
THE MACHINE HAVING THAT PORT 
ADDRESS HAS SUBSCRIBED TO 
DATA ON THAT TIB CHANNEL 


448 

J 


IF THE MESSAGE IS ON THE 
SUBSCRIBED SUBJECT. TIB- 
INFO CALLS THE CALLBACK 
ROUTINE OF THE 
SUBSCRIBING PROCESS AND 
PASSES rr A POINTER TO THE 
MESSAGE IN LOCAL MEMORY 


456 

J 






1 




DAEMON PUTS MESSAGE INTO 
APPROPRIATE INTERPROCESS DATA 

CALLBACK ROUTINE IN DCC UBRARY 
OF THE SERVICE LAYER 
ENCAPSULATING THE SERVICE 
DISCIPUNE THAT CALLED THE 
PROTOCOL ENGINE TO START THE 
SUBSCRIPTION TO NOTIFY IT OF A 
MESSAGE AND WHERE TO FIND 
SAME. DCC UBRARY CALLBACK 
ROUTINE WRITES MESSAGE INTO- 
LOCAL MEMORY OF SUBSCRIBING 
PROCESS AND CALLS CALLBACK 
ROUTINE OF SERVICE DISCIPUNE 
TO PASS rr A POINTER TO MESSAGE 


450 


SUBSCRIBING PROCESS 
rmi riicvc.d inc mcdoAoc 
AND USES IT FOR 
WHATEVER PURPOSE IT IS 
NEEDED 


458 


♦ 








SERVICE DISCIPLINE CALLBACK 
ROUTINE RUNS. RETRIEVES 
MESSAGE FROM LOCAL MEMORY 
USING POINTER FROM DCC UBRARY 
CALLBACK ROUTINE. DOES ANY 
NECESSARY DATA FORMAT 
CONVERSION AND CALLS CALLBACK 
ROUTINE OF THE TIB-INFO 
INTERFACE UBRARY ON THE 
INFORMATION LAYER 


452 


FIGURE 20B 




. , ■ ... 
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500 



DCC LIBRARY RECEIVES REQUEST 
FROM SERVICE DISCIPLINE TO SEND A 
MESSAGE HAVING A TIB CHANNEL 
ASSIGNED BY SERVICE DISCIPUNE 



502 



DCC UBRARY CHECKS SUBSCRIPTION 
UST TO DETERMINE HOW MANY 
SUBSCRIBERS THERE ARE TO THIS TIB 
CHANNEL 




IS 

IT MORE 
EFFICIENT TO 
SEND THE MESSAGE 
POINT-TO-POINT?. 



506 



YES 



CALL THE POINT-TO-POINT 
PROTOCOL ENGINE AND 
SEND THE MESSAGE POINT- 
TO-POINT 



NO 



r 



508 



CALL THE RELIABLE 
BROADCAST ENGINE 



510 



ADD SEQUENCE Nl 
CHANNEL NUMBER 
HEADERS AND SEN 
MESSAGES TO SUB 


IMBERSANDTIB 
S TO PACKET 
D ANY NECESSARY 
SCRIBER PROCESS 


512-^ 


r 



END 



WRITE ALL PACKETS WITH THEIR 
SEQUENCE NUMBERS AND TIB CHAN- 
NEL NUMBERS TO A RETRANSMIT MEM- 
ORY IN CASE ONE OR MORE PACKETS 

NEED TO BE RETRANSMITTED 

^ 

CONTD FIGURE 21 B 

FIGURE 21 A 
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FROM FIGURE 21 A 



514^ 



SEND MESSAGES TO ALL 
SUBSCRIBING PROCESSES FOR 
THIS TIB CHANNEL TO LISTEN FOR 
DATA ON THEIR REQUESTED 
SUBJECT ON TiB CHANNEL XX 
WHERE XX IS THE TIB CHANNEL 
ASSIGNED TO THIS SUBJECT 



516 



1 



TRANSMIT PACKETS VIA 
STANDARD BROADCAST 
PROTOCOLS OF TRANSPORT 
UYER 



FIGURE 21 B 
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518 



COMMUNICATION LAYER OF 
SUBSCRIBING PROCESS NOTIFIED 
OF ARRIVING PACKETS BY 
TRANSPORT PROTOCOL AND 
RETRIEVES PACKETS FROM 
INTERPROCESS TRANSFER 
MECHANISM 



520 



2i 



IF TIB CHANNEL NUMBER IN 
PACKET HEADERS MATCH AN 
OPEN SUBSCRIPTION BY A CLIENT 
PROCESS. THE RELIABLE 
BROADCAST PROTOCOL ENGINE 
OF DAEMON CHECKS REUABILITY 
SEQUENCE NUMBERS AGAINST 
DATA REGARDING SEQUENCE 
NUMBERS THAT MAKE UP THE 
ENTIRE MESSAGE AND ERROR 
CHECKING IS PERFORMED IN 
SOME EMBODIMENTS 



522 



RECEIVING COMMUNICATION 
UYER SENDS MESSAGE BACK TO 
TRANSMITTING COMMUNICATION 
LAYER SAYING EITHER THAT ALL 
PACKETS NAVE BEEN 
SUCCESSFULLY RECEIVED OR 
ASKING THAT CERTAIN PACKETS 
BE RETRANSMITTED 



COMMUNICATION LAYER OF 
SERVICE OR DATA PUBLISHING 
PROCESS RETRANSMITS MISSING 
OR GARBLED PACKETS 



T 



CONTD FIGURE 22 B 



FIGURE 22 A 
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FROM FIGURE 22 A 



526 



1 



RECEIVING COMMUNICATION 
LAYER VERIFIES THAT 
REPLACEMENT PACKETS HAVE 
BEEN CORRECTLY RECEIVED AND 
ACKNOWLEDGES THIS FACT TO 
THE COMMUNICATION LAYER OF 
THE SERVICE OR DATA 
PUBLISHING PROCESS OR AGAIN 
REQUESTS RETRANSMISSION OF 
MISSING OR GARBLED PACKETS 
AND PROCESS REPEATS UNTIL 
ALL PACKETS SUCCESSFULLY 
RECEIVED AND FINAL 
ACKNOWLEDGMENT MESSAGE IS 
SENT 



528 



I 



TRANSMITTING RELIABLE 
BROADCAST PROTOCOL ENGINE. 
UPON RECEIPT OF FINAL 
ACKNOWLEDGMENT MESSAGE OF 
SAFE RECEIPT OF ALL PACKETS, 
FLUSHES PACKETS FROM 
RETRANSMISSION MEMORY 



530 



2i 



RECEIVING PROTOCOL ENGINE 
CHECKS TIB CHANNEL DATA 
AGAINST SUBSCRIPTION LIST AND 
PASSES POINTER TO SERVICE 
DISCIPLINES LINKED TO ALL 
SUBSCRIBING PROCESSES 



532 



MESSAGES PASSED THROUGH 
SERVICE AND INFORMATION 
LAYERS TO SUBSCRIBING 
PROCESSES 



RGURE22B 
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600 >^ 






♦ ^608 


SERVICE DISCIPLINE OF DATA 
PUBLISHING PROCESS RECEIVES 
A SUBSCRIBE REQUEST, PASSES 
IT THROUGH INFORMATION LAYER 
TO SERVICE AND ENTERS 
SUBSCRIPTION IN SUBSCRIPTION* 
LIST 






IF THE NUMBER OF SUBSCRIBERS 
IS ABOVE THE CUTOFF NUMBER 
ESTABLISHED BY THE COST 
FUNCTION, CALL THE PROTOCOL 
ENGINE FOR RELIABLE 

BROADCAST AND PUT THE 

MESSAGE IN AN INTERPROCESS 
TRANSFER MECHANISM TO THIS 
PROTOCOL ENGINE 


i 




MESSAGE PUBUSHED BY SERVICE 
THROUGH INFORMATION LAYER 
TO SERVICE LAYER 










IF NOT, CALL THE POINT-TO-POINT 
PROTOCOL ENGINE AND PUT THE 
MESSAGE IN AN INTERPROCESS 
TRANSFER MECHANISM TO THIS 
PROTOCOL ENGINE 


604-^ i 


SERVICE DISCIPLINE OF SERVICE 
LAYER DETERMINES HOW MANY 
SUBSCRIBERS THERE ARE FOR 
THIS SUBJECT. AND ASSIGNS A 
TIB CHANNEL IF NECESSARY 






\ ^612 




AWAIT NEXT MESSAGE OR 
SUBSCRIPTION AND RETURN TO 
STEP 600 IF A SUBSCRIPTION OR 
STEP 602 IF A MESSAGE 


606 >^ 1 




SERVICE DISCIPUNE COMPARES 
NUMBER OF SUBSCRIBERS FOR 
THIS SUBJECT TO A 
PROGRAMMABLE CUTOFF 
NUMBER BASED UPON A COST 
FUNCTION OF COSTS FOR 
TRANSMISSION POINT-TO-POINT 
VERSUS BY RELIABLE 
BROADCAST 
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APPARATUS AND METHOD FOR 
PROVIDING DECOUPLING OF DATA 
EXCHANGE DETAILS FOR PROVIDING 
HIGH PERFORMANCE COMMUNICATION 

BETWEEN SOFTWARE PROCESSES S 

Hiis is a ccmtiniiation-iii-part aiiplication of a U.S. patent 
application entitled **Apparatus and Method foe Providing 
Decoupling of Data Exchange Detail& for Providing Ifigh 
Peiformanoe Communications Between Software Pro- lo 
cesses*", U.S. Ser. Na 07/601,117, now U.S. Pat No. 5,257, 
369, filed Oct 22, 1990 which is a continuation-in-pait 
application of U.S. Set No. 07/386^84, now U.S. Pat No. 
5.187,787 filed JuL 27, 1989. 



BACKGROUND OF THE INVENTION 

The invention peitains to the field of decoupled infionna- 
tion exchange between soltwaie processes lunning on dif> 
ferent or even the same computer where the software pro- 
cesses may use different foimats for data representation and 
oiganization or may use the »gtnp. formats and organization 
but said formats and oiganization may later be changed 
witiiout requiring any reprogiamming: Also, the software 
processes use "semantic" or field-name information hi such 
a way that each process can understand and use data it has 
received from any foreign soitwaie process, regardless of 
■Q^m^nfi c or field p^^iw^ differences. The semantic in£snna* 
tion is decoupled from data representation and organization 
information. 



2 

Further, many software modules between which communi- 
cation is to take place reside on different computers that are 
physically distant firom each other and connected only local 
area networks, wide area networks, gateways, satellites, etc. 
These various networks have their own widely diverse 
protocols for communication. Also, at least in the world of 
financial services, the various sources of raw data such as 
Dow Jones News or Telerate"^ use different data formats 
and communication protocols v/bich must be understood 
and followed to receive data from these sources. 

In complex data situations such as financial data regarding 
equities, bonds, money markets, etc, it is often useful to 
have nesting of data. That is, data regarding a particular 
subject is often organized as a data record having multiple 
"fields," each field pertaining to a different aspect of the 
subject It is often useful to allow a particular field to have 
subfields and a particular subfield to have its own subfields 
and so on fiDr as-many-levels as necessary.- For purposes of 
discussion herein, this type of data oiganization is called 
**nesting.'* The names of the fields and what they mean 
relative to the sut^ea will be called the "semantic informa- 
tion" for purposes of discussion herein. The actual data 
representation for a particular field, i.e., floating pomt, 
integer, alphanumeric, etc, and the oiganization of the data 
record in terms of how many fields it has, winch are 
primitive fields which contain only data, and which are 
nested fields which contain subfields, is called the "^faaassT 
or "type" information for purposes of discussion hesrein. A 
fidd which contams only data (and has so nested subfields) 
will be called a "primitive field,** and a field which contains 
other fields will be called a "constructed field" herein. 



Mth the proliferation of different types of computers and There are two basic types of operations that can occur in 
software programs and the ever-present need for different exchanges of data between software modules. Hie fint type 
types of computers running different types of software of operation is called a 'Tormat operation" and involves 
programs to exchange data, there has arisen a need for a ^ conversion of the format of one data record (hereafter data 
system by which such exchanges of data can occur. lypi- records may sometimes be called "a forms'*) to another 
cally, data that must be exchanged between software mod- format An example of such a format operation might be 
ules that are foreign to each other comprises text, data and conversion of data records with floating point and EBCDIC 
graphics. However, there occasionally arises the need to fields to data records having the padded representation 
exchange digitized voice or digitized image data or other ^ needed for transmission over an ETHERNET^ local area 
more exotic forms of information. These different types of network. At the receiving process end another format opera- 
data are called "prinutives" A software program can tion for conversion firom the ETHERNET"^ p^iket format 
manipulate only the primitives that it is programmed to to integer and ASCII fields at the receiving process or 
understand and manipulate. Other types of primitives, when software module might occur. Another type of operation will 
introduced as data into a software program, will cause be called herein a "semantic-dependent operation" because 
errors. it requires access to the semantic information as well as to 

"Foreign," as the term is used herein, means that the the type or format information about a fonn to do some woik 

software modules or host computers involved in the onthefonnsuchas to supply a particular field of that fonn, 

exchange "speak different languages." For example, the e.g., today's IBM stock price or yesterday's IBM low price. 

Motorola and Intdnncn)proccssorwiddy used m personal so to some software module that is requesting same. . 

computers and work stations use different data representa- Still further, in today's environment, there are often 

tions in that in one &mily of microprocessors the most multiple sources of different types of data and/or multiple 

significant byte of multibyte words is placed first while in sources of the same type of data where the sources overly 

the other family of processors the most significant byte is in coverage but use diffierent formats and different commu- 

placed last. Further; in IBM computers text letters are coded 55 nication protocols (or even overi^ with the same format and 

in EBCDIC code while in almost all other computers text the same communication protocol). It is iiseful for a software 

letters are coded in ASCII code. Also, tiiere are several module (software modules may hereafter be sometiihes 

different ways of representhig numbers including integer, referred to as "applications") to be able to obtam informa- 

floating point, etc. Further, foreign software modules use tion regarding a particular subjea without knowing the 

different ways of organizing daia and use different semantic gg networic address of the service that provides information of 

information, i.e., what each field in a data record is named that type and without knowing the details of the particular 

and what it means. communication protocol needed to communicate witii that 

The use of various formats for data represratation and information source, 

oiganization means diat translations ddier to a common A need has arisen therefore for a oonununicaticm system 

language or firom the language of one computer or process 65 which can provide an interface between diverse software 

to the language of another con^uter or process must be modules, processes and computers for reliable, meaningful 

. made before meaningfiil communication can. take place: exchanges of data while "decouplmg" these software mod- 
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. ales and computers. *^ecoupling" means that the software 
module programmer can access infbrmatian &om other 
coiiq}Uters or software processes without knowing where the 
other software modules and computers arc in a network, the 
format that forms and data take on the foreign software, 5 
what communication protocols are necessary to communi- 
cate with the fcEdgn software modules or computers, or 
what communication protocols are used to transit any net- 
works between the source process and the destination pro- 
cess: and without knowing which of a multiple of sources of to 
raw data can supply the requested data. Ftairther, "decou- 
pling," as the term is used herein, means that data can be 
requested at one time and supplied at another and that one 
process may obtain desired data from the instances of forms 
created with foreign format and foreign semantic data 15 
through the exercise by a communication interface of appro* 
priate semantic opmtioris to extract the requested data ih)m 
the foreign fbrrns with the extraction process being trans- 
parent to the requesting process. 

Various systems exist in the prior art to allow information 20 
exchange between foreign software modules with various 
degrees of decoupling. One such type of system is any 
electronic mail software which implements Electronic 
Document Exchange Standards including CCTTT's X409 - 
standard. Bectronic mail software decouples applications in ^ 
the sense that format or type data is included within each 
instance of a data record or form. However, there are no 
provisions for recoidiQg or processing of semantic informa- 
tion. Semantic operations such as extraction or translation of 
data based upon the name or meaning of the desired field in 30 
the foreign data structure is therefore impossible. Semantic- 
Dependent Operations are very inqxntant if successful com- 
munication is to occuL Further, there is no provision in 
Electronic Mail Software by which subject-based addressing 
can be implemented wherem the requesting zppUcmdan 35 
siniply asks for information by subject without knowing the 
addr^ of the source of information of that type. Further, 
such software cannot access a service or network for which 
a communication protocol has not already been established. 

Relational Database Software and Data Dictionaries are ^ 
another example of software systems in the prior art for 
allowing foreign processes to share data. The shortcoming of 
this class of software is that such programs can handle only 
"fiat*- tables, records and fields within records but not nested 
records within records. Further, the above-noted sbortcom- 
ing in Electronic Mail Software also exists in Relaliona] 
Database Software. 

SUMMARY OF THE INVENTION 50 

According to the teachings of the invention, there is 
provided a method and apparatus for providing a structiue to 
interface foreign processes and computers while providing a 
degree of decoupling heretofore unlcnowrL S5 

The data communicatioD interface software system 
according to the teachings of the invention consists essen- 
tially of several libraries of programs organized into two 
major conq)onents, a communication coniponent and a 
data-exchange con^nent Interface, as die term is used 60 
herein the context of the invention, means a oollecdon of 
functions which may be invoked by the application to do 
useful work in communicating with a foreign process or a 
foreign computer or both. Invtddng functions of the inter- 
face may be by subrouthie calls from the application or from 65 
another component in the communications interface accord- 
ii^ to the invendon. 
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In the preferred embodiment, the functions of the inter- 
face are carried out by the various subroutines in the libraries 
of subroutines which together comprise the interface. Of 
course, those skilled in the art will eqppreciate that separate 
programs or modules may be used instead of subroutines 
and may actually be preferable in some cases. 

Data format decoupling is provided such that a first 
process using data reccnds or forms having a first format can 
communicate with a second process which has data records 
having a second, difierent format without the need for the 
first process to know or be able to deal with the format used 
by the second process. This form of decoupling is imple- 
mented via the data-exchange component of the comnmni- 
cation interface software system. 

The data-exchange component of the communication 
interface according to the teachings of the invention includes 
a forms-manager module and a forms-class manager mod- 
ule. The forms-manager module handles the aeadon, stor- 
age, recall and destxucdon of Instances of forms and calls to 
the various functions of the forms-class manageiu Hie latter 
handles the creation, storage, recaU, interpretation, and 
destmction of forms^ass descriptors which axe data records 
which record .thc format and semantic information that 
pertain to particular dasses of forms. Hie forms-class man- 
ager can also receive requests from the application or 
another component of the conmiunication interface to get a 
particular field of an instance of a form when identified by 
the name or meaning of the field, retrieve the appropriate 
form instance, and and deliver the requested data in the 
appropriate field. The forms-class manager can also locate 
the dass definition of an unknown dass of forms by looking 
in a known rqx)sitory of such dass definitions or by 
requesting the class definition from the forms-class manager 
linked to the foreign process which created the new class of 
form. Semantic data, such as field names, is decoupled from 
data representation and organization in the sense that seman- 
tic information contains no information regarding data rep- 
resentation or organization. The communication interface of 
the invention implements data decoupling in the semantic 
sense and in the data format sense. In the semantic sense, 
decoupling is implemented by virtue of the ability to carry 
out semantic-dependent operations. These operations allow 
any process coupled to the communications interface to 
exchange data with any other process which has data orga- 
nized either the same or in a different marmer by using the 
same field names for data which means the same thing m the 
preferred embodiment In an alternative embodiment seman- 
tic-dqiendent operations implement an aliasing or synonym 
conversion facility wherel^ incomirig data fidds having 
difierent names but whidi mean a certain thing are either 
relabded with fidd names understood by the requesting 
process or are used as if they had been so relabded. 

The interface according to the teachings of the invention 
has a process architecture organized in 3 layers. 

Architectural decoupling is provided by an information 
layer such that a requesting process can request data regard- 
ing a particular subject without knowing the network 
address of the server or process where the data may be 
found. This form of decoupling is provided by a subject- 
based addressing system within the information layer of the 
communication component of die interface. 

Subject-based addressing is implemented by the commu- 
nication component of the oommimication interface of the 
invention by subject mapping. The communication compo- 
nent receives ''subscribe" requests from an application 
which spedfies the subject upon which data is requested. A 
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subjea-mapper module in the infonnation layer receives the 
request firom the application and then looks up the subject in 
a database, table or the like. The database stores "service 
records" which indicate the various server processes that 
supply data on various subjects. Tlie appropriate service 
record identifying the particular server process that can 
supply data of the requested type and the communication 
protocol (hereafter sometimes called the service disdpUne) 
to use in oonununicating with the identified sender process is 
returned to the subject-mapper module. 

The subject mapper has access to a plurality of commu- 
nications library programs or subroutines on the second 
layer of the process architecture called the service layer. The 
routines on the service layer are called 'Wvice disciplines." 
Each service discipline encapsulates a predefined commu- 
nicatioD protocol which is specific to a server process. The 
subject mapper then invokes the apprcqniate service disci- 
pline.identified in the service record — . . 

The service discipline is givoi the subject by the subject 
mapper and proceeds to establish communications with the 
appropriate server process. Thereafter, instances of forms 
containing data regaidii^ the subject are sent by the server 
process to the requesting process via the service discipline 
which established the communicatian. 

Service protocol decouplii^ is provided by the service 
layet. 

Temporal decoupling is implemented in some service 
disciplines dkected to page-oriented server processes such 
as Tbierate™ by access to real-time data bases which store 
updates to pages to which subscriptions arc outstandmg. 

A third layer of the distributed communication component 
is called the communication layer and provides configura- 
tion decoupling. This layer includes a DCC libraiy of 
programs that receives requests to establish data links to a 
particular server and determines the best communication 
protocol to use for the link unless the protocol is already 
established by the request The communication layer also 
includes protocol engines to encapsulate various communi- 
cation protocols such as point-to-point, broadcast, reliable 
broadcast and the Intelligent Multicast™ protocol. Some of 
the functionality of the communication layer augments the 
functionality of the standard transport protocols of the 
operating system and provides value added services. 

One of these value added services is the reliable broadcast 
protocol. Tins protocol eqgine adds sequence numbers to 
packets of packctized messages on the transmit side and 
verifies that all packets have been received on the receive 
side. Packets are stored for retransmission on flie transmit 
side. On the receive side, if all packets did not come in or 
some are garbled, a request is sent for retransmission. The 
bad or missing packets are then resent When all packets 
have been succ^sfuliy received, an acknowledgment mes- 
sage is sent This causes the transmit side protocol engine to 
fiush the packets out of the retransmit buffer to make room 
for packets of the next message. 

Another valiie added service is the Intelligent Multicast 
Protocol. This protocol involves the service discipline exam- 
ining the subject of a message to be sent and determining 
how many subscribers there are for this message subject If 
die number of subscribers is below a threshold set by 
deteimimng costs of point-to-point versus broadcast trans- 
mission, the message is sent point-to-point Otiierwise the 
message is sent by the reliable broadcast protocol. 

BRIEF DESaUPnON OF THE DRAWINGS 

65 

FIG. 1 is a block diagram illustcating the relationships of 
the various -software modules of the communication inter- 
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face of one embodiment of the invention to client applica- 
tions and tiie networi^ 

FIG. 2 is an example of a form-class definition of the 
constructed varie^. 

FIG. 3 is an example of another constructed form-class 
definition. 

FIG. 4 is an example of a constructed fonn-dass defini- 
tion containing fields diat are themselves constnicted forms. 
Hence, this is an example of nesting. 

FIG. 5 is an example of three primitive form classes. 

FIG. 6 is an exanq)le of a typical form instance as it is 
stored in memory. 

FIG. 7 illustrates the partitioning of semantic data, format 
data, and actual or value data betv^een the form-class defi- 
nition and the form instance. 

FIG. 8 is a flow chart of processing during a format 
operation. 

FIG. 9 is a target format-specific table for use in format 
operations. 

FIG. 10 is another target foimat-^)ecific table for use in 
format operations. 

FIG. 11 is an exairple of a general conversion table for 
use in format operations. 

FIG. 12 is a flow diatt for a typical semantic-dependent 
operatioiL 

FIGS. 13A and 13B are, respectively, a class definition 
and the class descriptor form which stores tiiis class defini- 
tion. 

FIG. 14 is a block diagram iihifitmtiTig the relationships 
between flie subgea-mapper module and the service disd- 
pluie modules of die communication component to the 
requesting application and the service for subject-based 
addressing. 

FIG. 15 illustrates the relationship of the various modules, 
libraries and interfaces of an alternative embodiment of the 
invention to the client applications. 

FIG. 16 illustrates the ielationshq)s of various modules 
inside the communicaticHi interface of an alternative 
embodiment 

FIG. 17 is a block diagram of a typical distributed 
computer network. 

FIG. 18 is a process architecture showing the relationsMp 
of the DCC libraiy to the DCC protocol engines in the 
daemoa 

HG. 19, comprised of FIGS. 19A and 19B, is a flow 
diagram of the process which occurs, inter alia, at the three 
layers of the software of the invention where a subscribe 
request is sent to a service. 

HG. 20, conqnised of FIGS. 20A and 20B. is a flow chart . 
of the process which occurs at, inter alia, the three layers of 
die software interface according to the teachings of the 
invention when a subscribe request is received at a . data 
producing process and messages flow back to the subscrib- 
ing process. 

FIG. 21, comprised of FIGS. 21A and 21B, is a flow chart 
of die process which occurs at the DCC library and in the . 
reliable broadcast protocol engine when messages are soit 
by the reliable broadcast protocol. 

FIG. 22, comprised of FIGS. 22A and 22B, is a flow chart 
of jffocessing by a reliable broadcast protocol engine on die 
da^ consumer side of the reliable broadcast transaction. 

FIG. 23 is a flow chart of the processing which occurs in 
the service disci|dine to implement the Intelligent Multi- 
casf'M protocol 
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DETAILED DESCRIPTrON OF THE 
PREFERRED AND ALTERNATIVE 
EMBODIMENTS 

Since the following description is highly techmcal. it can 
best be understood hy anunderstanding of the terms used in ^ 
the digital network telecommunication art defined in the 
appended glossary. Hie reader is urged to read the glossary 
at the end of the specification herein fiist 

Referring to FIG. 1 there is shown a block diagram of a 
typical system in which the communications interlace of the 
invention could be incorporated, although a wide variety of 
^stem architectures can benefit from the teachings of the 
invention. Hie communication inteifiace of the invention 
may be sometimes hereafter refened to as the TIB^ or ^. 
Teknekron Information Bus in the specification of an alter- 
native embodiment given bdow. Hie reader is urged at this 
''point to^study the glossary of tdrms included in this sped- 
fication to obtain a basic understanding of some of the more 
inqMirtBm ternis used hodn to describe the invendon. T^ ^ 
teachings of tbt invention are incorporated in several binar- 
ies of computer programs wUdi, taken together* provide a 
communicalion interface having many functional capabili- 
ties which facilitate modularity In client application devel- 
opment and changes in netwoik communication or service ^ 
communication {Hotocols by coupling of various client 
applications tog^her in a "decoupled*' fashioa Hereafter, 
the teachings of the invention will be referred to as tte 
communication interface. 'Decoupling,*' as the t^m is used 
herein^ means that the programmer of client ^plication is ^ 
&eed of the necessity to know the details of the communi- 
cation protocols, data rqyiesentation format and data recasrA 
organization of all the other applications or services with 
which data exchanges are desired. Further, the programmer 
of the client application need not know the location of 
services or servers providing data on particular subjects in 
Older to be able to obtam data on these subjects. The 
communication interim automatically takes care of all the 
details in data exchanges between client applications and 
between data-consumer applications and data-provider scr- ^ 
vices. ^ 

The system shown in FIG. 1 is a typical netwoik coupling 
multiple host computers via a netwoik or by shared memory. 
Two host computes, 10 and 12, are shown in FIG. 1 lunning 
two client ^jplications 16 and 18, although in other embodi- 45 
ments these two client applications may be running on the 
same computer. These host computers are coupled by a 
network 14 which may be any of the known netwoiics such 
as the ETHERNET™ communication protocol, the token 
ring protocol, etc. A network for exchanging data is not 50 
required to practice the invention, as any method of 
exchangmg data known in the prior art will sufElce for 
purposes of practicing the invention Accordingly, shared 
memory files or shared distributed stcnage to which the host 
computers 10 and 12 have equal access will also suffice as 55 
the environment in which the teachings of the invention are 
i^licable. 

Each of the host computers 10 and 12 has random access 
memory and bulk memory such as disk or tape drives 
associated therewidi (not shown). Stored in these memories 60 
are the various operating system programs, client applica- 
tion programs, and. other programs such as the programs in 
the libraries that together comprise the commimication inter- 
face which cause the host computers to perform useful work. 
The libraries of programs in the communication interface 65 
provide basic tools which may be called upon by client 
plications to do such things as find the location of services 
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that provide data on a particular sulyect and establish 
communications with that service using the q)propriate 
commimication protocol. 

Each of the host computers may also be coupled to user 
interfiaoe devices such as terminals^ printers, etc. (not 
shown). 

In the exen^laiy system shown in FIG. 1, host compiter 
10 has stored in its memory a client 2q>plication program 16. 
Assume that this client qiplication program 16 requires 
exchanges of data with another client application program or 
service 18 controlling host computer 12 in order to do usefol 
work. Assume also that the host computers 10 and 12 use 
difierent formats for representation of data and that qypli- 
cation programs 16 and 18 also use different formats for dtta 
rqnesentation and aiganization for the data records created 
thereby. These data records will usually be referred to herein 
as forms. Assume also that the data patii 14 between the host 
conq)uters'l Q'and' 12 is cbnipHsied of a local ari» netwoik of 
tiie ETHERNET™ variety. 

Each of the host processors 10 and 12 is also programmed 
with a library of programs, whidi together comprise the 
communication interfaces 20 and 22, respectively. The com- 
munication interface programs are either linked to Uie com- 
piled code of the client sqpplications by a linker to generate 
run time code, or the source code of the communication 
programs is inrfnderi with the source code of the client 
plication programs prior to oompifiqg. In, any event, the 
communication library programs are somdidw bound to the 
client application. Thus, if host computer 10 was runmng 
two client plications, each client application would be 
bound to a commumcation interface module such as module 
20, 

The purpose of the communications interface module 20 
is to decouple application 16 firom the detaOs of the data 
format and organization of data in forms used by application 
18, the n^cMrk address of application 18, and the details of 
the communication protocol used by application 18, as well 
as the details of the data format and organization and 
conununication protocol necessary to send data across net- 
work 14. Communication interface module 22 serves the 
same fiinction for plication 18, tiiereby freeing it from the 
need to know many details about the application 16 and the 
netwoik 14. The communicatian interface modules fodlitate 
modularity in that changes can be made in client applica- 
tions, data formats or organizations, host computers, or the 
networks used to couple all of die above togedier witiiout the 
need for these changes to ripple throughout die system to 
ensure continued compatibility. 

In order to implement some of these functions, the com- 
munications interfaces 20 and 22 have access via the net- 
work 14 to a netwoik file system 24 which includes a subject 
table 26 and a service table 28. These tables will be 
discussed in more detail below with reference to the dis- 
cussion of subject-based addressing. These tables list the 
netwoik addresses of services that provide information on 
various subjects. 

A typical system model in which the communication 
interface is used consists of users, users groups, networks, 
services, service instances (or servers) and subjects. Users, 
representing human end users, are identified by a user-ID. 
The user ID used in the communications interface is nor- 
mally the same as the user ID or log-on ID used by the 
underlying operating system (not shown). However, tiiis 
need not be the case. Each user is a member of exacdy one 
group. 

Groups are comprised of users with similar service access 
patterns and access rights. Access rights to a service or 



04/19/2004, EAST Version: 1.4.1 



5.557,798 



9 

system objea are grantable at the level of users and at the 
level of groups. The system administrator is responsible for 
assigning users to groups. 

A "network," as the term is used herein, means the 
underiymg ^transport layer" (as the term is used in the ISO 
network Idyct model) and all layers beneath the transport 
layer in the ISO network model An application can send or 
receive data across any of the networks to which its host 
computer is attached. 

The communication interface according to the teachings 
of the invention, of which blocks 20 and 22 in FIG. 1 are 
exemplary, indudes for each client appHcation to which it is 
bound a communications component 30 and a datarcx- 
cfaange oon^xment 32. The communications component 30 
is a common set of conuninrication facilities which imple- 
ment, for exan^le, subject-based addressing and/or service 
discipline decoupling. The communications compcment is 
-linked to each client application. In addition^ each commu- 
nications component is linked to the standard transport layer 
protocols, e.g., TCP/IP» of the network to which it is coupled! 
Each communicati<Ki component is linked to and can sup- 
port multiple transport layer protocols. The transport layer of 
a network does the following things: it maps transport layer 
addresses to netwcvk addresses, multiplexes transport Is^ex 
cormections onto network connections to provide greater 
throughput, does error detection aiul monitoring of service 
quality, error recovery, segmentation and Mocking, flow 
control of individual connections of transport layer to net- 
wodc and session layers, and expedited data transfer. The 
communications componrait cooperates with the transport 
layer to provide reliable commiinications protocols for client 
qiplications as well as providing location transparency and 
netwo± independence to the dient q)plication8. 

The data-exdiange con^ment of the communications 
interface, of which component 32 is typical, implements a 
powerful way of repres^iting and transmitting data by 
encapsulating the data within self-describing data objects 
called forms. These forms are self-describing in that they 
mchide not only the data of interest, but also type or format 
uiformation which describes the representations used for the 
data and the orgamzadcxi of the form. Because the forms 
include this type or format information, fortnat operations to 
convert a particular form having one format to another 
format can be done using stiicdy the data in the form itself 
without the need for access to other data called dass 
descriptors or class definitions which give semantic infor- 
nmtion. Semantic information in class descr^tora basically 
means the names of the fields of the form. 

The ability to perform format operations solely with the 
data in the form itself is very important in that it prevents the 
delays encountered when access must be made to other data 
objects located elsewhere, such as dass descriptors. Since 
format operations alone typically account for 25 to 50% of 
the processing time for client plications, the use of sdf- 
describing objects streamlines processmg by rendering it 
faster. 

The self-describing forms managed by the data-exchange 
component also allow the implementation of generic tools 
for data manipulation and display. Such tools indude com^ 
munication tools for sending forms between processes in a 
machine-independent fonnat Further, since sdf-describing 
forms can be extended, i.e., their ox:ganization changed or 
expanded, without adversely impacting the dient applica- 
tions using said forms, such forms greatly fiodlitate modular 
application development 

Since the lowest layer of the communications intoface is 
linked with the transport layer of the ISO modd and since 
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the communications con^nent 30 includes multiple smice 
disdplines and multiple transport-layo- protocols to support 
multiple networks, it is possible to write application-ori- 
ented protocols which transparently switch over from one 

5 netwodc to another in the event of a network failure. 

A ''service" rc|nesents a meanixiglul set. of functions 
wfaidi are expoited by an appUcadon for use by its client ' 
applications. Examples of services are historical news 
retrieval services sudi as Dow Jones New, Quotron data 

^0 feed, and a trade tidcet router. Applications typically export 
only erne service, althou^ the export of many difiictent 
services is also possible. 

A **senrice instance*' is an a^lication or process capable 
of providing the given service. For a given service, several 
'Instances" may be concurraitly providing the service so as 
to improve the throughput of the service or provide fault 

- -tolerance. 

Although n^orks, services and seivera are traditioDal 

2Q components known in the prior art, prior art distribmed 
systems do not recognize, the notion of a subject space or 
data independence by selif-describing, nested data objects. 
Subject space supports one form of decoupling called sub- 
ject-based addressing. Self-describing data objects which 

2j may be nested at nmltiple levds are new. Decoupling of 
client applications firom the various communications proto- 
cols and data formats prevalent in other parts of the nptwock 
is also very useful. 
The subject space used to inclement subject-based 

30 addressing consists of a hierarchical set of subject catego- 
ries. In the preferred embodiment, a four-level subject space 
hierarchy is used. An example of a typical subject is: 
"equity.ibm.composite.trade." The client applications 
coupled to the communications interface have the freedom 

35 and responsibility to establish conventions regarding use and ' 
interpretations of various subjea categories. 

Eadi suligect is typically assodated with one or more 
services providing data about that subject in data records 
stored in the system files. Since each service will have 

40 assodated with it in file communication components of the 
communication intetfiEice a.servioe disdpline, Le., the com- 
munication protocol or procedure necessary to communicate 
with diat service, the dient applications may request data 
regarding a particular subject without knowing where the 

45 service instances that supply data on that subject are located . 
on the network by makii^ subscription requests giving cnily 
the subject witiiout the network address of the sendee 
providing information on that subject These subscription 
requests are translated by the communications interface into 

so an actual communication connection with one or more 
service instances which provide information on that subject 
A set of subject categories is rdened to as a subject 
domain. Multiple subject domains are allowed. Each domain 
can define domain-spedfic subject and coding functions for 

ss effidenUy representhig subjects in message headers. 

DATA INDEPENDENCE: The Data-Exchange 
Component 

50 The overall purpose of the data-exchange component such 
as component 32 in RG. 1 of the communication interface 
is to d^uple the client applications such as application 16 
from the details of data representation, data structuring and 
data semantics. 

65 Referring to FIG. 2, there is shown an example of a dass 
definition for a constructed dass which defines both fonnat 
and semantic information which is common to all instances 
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of fonns of this class. In the particular exan^le chosen, the 
fonn class is named Player_Name and has a class ID of 
1000. Tlie instances of forms of this dass 1000 include data 
regarding the names, ages and NTRP ratings far tennis 
players. Eveiy dass definition has associated with it a dass s 
number called the dass ID which uniquely idratifies the 
class. 

The class definition gives a list of fields by name and the 
data representation of the contents of die field. Each field 
contains a fonn and each form may be either primitive or 10 
constructed. Primitive class forms store actual data, while 
constructed dass forms have fidds which contain other 
forms which may be either pnmitive or constructed In the 
class definition of FIG. 2, thac are four fidds named Rating, 
Age, Last_Name and First_Name. Each field contains a 15 
pnmitive class form so each iidd in instances of forms of 
...this dass will-contain actual data. For- example, the field • - 
Rating will always contain a primitive form of dass 11. 
Qass 11 is a primitive dass named Floating_Point whidi 
specifies a floating-point dataieprcscntation for the contents ^ 
of this fidd. The primitive class definitian for the dass 
Floating-Point, dass 11, is found in HG. 5. The dass 
definition of the primitive dass 11 contains the dass name, 
Floating_Point, whidi uniqudy identifies the dass (the 
dass number, class 11 in tins example, also uniqudy idoi- 25 
tifies the dass) and a spedfication of the data representation 
of the single data value. The spedfication of tibe single data 
value uses well-known predefined system data types which 
are understood by both tiie host computer and the silica- 
tion dealing with this class of forms. 30 

Typical specifications for data representation of actual 
data values indude integer, floating point, ASCII character 
strings or EBCDIC character strings, etc. In the case of 
primitive dass 11, the spedfication of the data value is 
Floating__Point_l/l which is an arbitrary notation indicat- 
ing that the data stored in instances of forms of this pnmitive 
class will be floating-point data having two digits total, one 
of which is to the ri^t of the decimal point 

Returning to the consideration of the Player_Name dass ^ 
definition of FIG. 2, the second fidd is named Age. Tliis fidd 
contains forms of die primitive dass named Int^go* assod- 
ated with dass number 12 and defined in FIG. 5. TTie Integer 
dass of fiwm, dass 12, has, per die class definition of FIG. 
5, a data representation specification of Integer_3, meaning 
the fidd contains integ^ data having three digits. The last 
two fidds of tiie class 1000 definition in FIG. 2 are Last_ 
Name and First_Name. Both of these fidds contain primi- 
tive forms of a dass named String_l>¥enty^ASCn, dass 
10. The class 10 dass definition is given in FIG. 5 and ^ 
spedfies that instances of forms of this class contain ASCII 
character strings which are 20 characters long. 

FIG. 3 gives another constructed class definition named 
Player_Address, class 1001. Instances of forms of this class 
each contain thrce fields named Street, City and State. Each 55 
of these three fields contains primitive forms of the class 
named String_20_^ASCII, class 10. Again, the class defi- 
nition for dass 10 is given in FIG. 5 and specifies a data 
representation of 20-character ASCII strings. 

An example of the nesting of constructed dass forms is 60 
given in FIG. 4. FIG. 4 is a dass definition for instances of 
forms in the dass named Tbuniament_Entry, class 1002. 
Each instance of a farm in this class contains three fidds 
named Ibumament^ame, Player, and Address. The fidd 
Toumamcnt_J^ame indudes forms of the primitive class 65 
named String_Twcnty_ASCII. class 10 defined in FIG. 5. 
The field named Player contains instances of constructed 
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forms of the class named Player_Name, class 1000 having 
the format and semantic characteristics given in FIG. 2. The 
field named Address contains instances of the constructed 
form of constructed forms of the constructed class named 
Player^ddress, dass 1001, which has the format and 
semantic characteristics given in the dass definition of FIG. 
3. 

The dass definition of FIG. 4 shows how nesting of fonns 
can occur in tiiat each field of a form is a form itsdf and 
every form may be dther primitive and have only one field 
or constnicted and have several fidds. In other words, 
instances of a form may have as mai^ fields as necessary, 
and each fidd may have as many subfields as necessary. 
F^mher, each subfidd may have as maziy sub-subfidds as 
necessary. Thb nesting goes on for any aibitraiy number of 
levds. This data stnicture allows data of arbitrary oon^lex- 
ity to be easfly r e pr e s en ted and manipulated. 
~^ Riefening to FIG. 6 there is sliown an ini^oe of a form 
of the dass of forms named Ibumament.Entry, dass 1002, 
as stored as an object in memory. The block of data 38 
contains the constructed dass number 1002 indicating that 
this is an instance of a form of the constructed class named 
Toumament_JEntry. The block of data 40 indicates that this 
dass of form has tiiree fidds. Hiose three fields have blocks 
of data shown at 42, 44, and 46 containing the class numbers 
of the forms in these fidds. Tlie block of data at 42 indicates 
that the first field contains a form of class 10 as shown in 
FIG. 5. A dass 10 form is a primitive form containing a 
20-character string of ASCII characters as defined in the 
class definition for class 10 in FIG. 5. The actual string of 
ASCII characters for this particular instance of tins form is 
shown at 48, indicating that this is a tournament entry for the 
U.S. Open teimis tournament. The block of data at 44 
indicates that the second field contains a form which is an 
instance of a constructed form of dass 1000. Reference to 
this dass defiiution shows that this class is named Player_ 
Name. The blod^ of data 50 shows that tliis dass of 
constructed form contains fom subfields. Those fields con- 
tain forms of the dasses recorded in the blodcs of data 
shown at 52, 54, 56 and 58. These fidds would be subfidds 
of the fidd 44. Tlie first subfidd has a block of data at 52, 
indicating that this subfidd contains a fonn of primitive 
dass U. This dass of form is d^ned in FIG. 5 as containing 
a floatmg-point two-digit number with one decimal place. 
Hie actual data for this instance of the form is shown at 60, 
mdicatir^ that this player has an NTRP xating of 3 J. The 
second subfidd has a block of data at 54, uadxcating that this 
subfidd contains a form of primitive class 12. The class 
definition for this dass indicates that the class is named 
integer and contains integer data. Tlie dass definition for 
class 1000 shown in FIG. 2 indicates that tiiis integer data, 
shown at block 62, is the player's age. Note that the dass 
definition semantic data regarding fidd names is not stored 
in the form instance. Only the format or type information is 
stored in the form instance in the form of the class ID for 
each fidd. 

The third subfield has a block of data at 56, indicating that 
this subfidd contains a form of primitive dass 10 named 
String_20_ASCn. This subfield corresponds to the fidd 
LastJMame in tiie form of dass Player_Name, dass 1000, 
shown in HG. 2. The primitive dass 10 dass definition 
spedfies that instances of this primitive dass contain a 
20-character ASCD string. This string happens to define the 
player's last name. In die instance shown in RG. 6, die 
player's last name is Blackett, as shown at 64. 

The last subfidd has a block of data at 58, indicating that 
the field contains a primitive form of primitive dass 10 
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which is a 20-character ASCII string. This subfield is defined 
in the class definition of class 1000 as containing the 
player's first name. This ASCII string is shown at 66. 

The third lield in the instance of the form of class 1002 has 
a block of data at 46, indicating that this field contains a ^ 
constructed fonn of Ate oonstnicted dass 1001. The class 
definition for this class is given in FIG. 3 and indicates the 
class is named Player.Addiess. The block of data at 68 
indicates that this field has three subfields containing forms 
of the dass numbers indicated at 70, 72 and 74. Tliese 
subfidds each contain forms of the primitive class 10 
defined in FIG. 5. Each of these subfidds therefore contains 
a 20-character ASCII string. Tbc contents of these three 
fields are defined in the class definition for class 1001 and 
are, respectivdy, the street, dty and state entries for the i^ 
address of the player nampid in the field 44. These 3-char- 
act^, strings are shown at 76,. 78. and 80, respeotiyely. 

Referring to FIG. 7, there is shown a partition of tiie 
semantic information^ format information and actual data 
between the class definition and instances of forms of this ^ 
dass. The fidd name and format or type information are 
stored in the class definition, as indicated by box 82. The 
format or type information (in the form of the class ID) and 
actual data or fidd values are stored in the instance of the'' 
fionn as shown by box 84. For example, in the instance of the ^ 
fonn of dass Ibunuunent^^Entiy, dass 1002 shown in FIG. 
6, the format data for the first fidd is the data stared in block 
42, while the actud data for the fint field is the data shown 
at blodc 48. Essentially, the dass number or class ID is 
equated by the communications interfoce with the spedfi- ^ 
cation for the type of data in instances of f onns of that 
primitive dass. Huis, the commumcatioDS intci&oe can 
peiform format operations on instances of a particdar form 
using only the format data stored in the instance of the form 
itself without the need foe access to die dass definition. This ^ 
speeds up format operations by eliminating the need for the 
performance of the steps required to access a class definition 
which may indude networic access and/or disk access, 
which would substantially slow down the operatioa Since 
format-type opcradons comprise the bulk ofdl operations in ^ 
exchanging data between foreign processes, die data struc- 
ture and the library of programs to handle the data structure 
defined herein greatly increase the. effidency of data 
exchange between fordgn processes and foreign computers. 

For example, suppose that the instance of the form shown 
in FIG. 6 has been generated by a process running on a 
conpiter by Digital Equipment Corporation (DEC) and 
therefore text is expressed in ASCQ characters. Suppose dso 
that this form is to be sent to a process running on an IBM ^ 
computer, where character strings are expressed in EBCDIC 
code. Suppose also that these two computers were coi^led 
by a local area network using die ETHERNET'^ commu- 
nications protocol 

Tb make this transfer, several format operations would 55 
have to be performed. These format operations can best be 
understood by reference to FIG. 1 with the assumption that 
the DEC computer is host 1 shown at 10 and the IBM 
computer is host 2 shown ai 12. 

The first format operation to transfer the instance of the 60 
form shown in FIG. 6 from application 16 to application 18 
would be a conversion from the format shown in FIG, 6 to 
a packed format suitable for transfer via networic 14. Net- 
works typically operate oii messages conqnised of blocks of 
data comprising a plurali^ of bytes packed together end 10 65 
end preceded by nuiltiple bytes of header information which 
indude such things as the message length, the destination 
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address, the source address, and so on, and having error 
correcdon code bits appended to the end of the message. 
Sometimes ddimiters are used to mark the start and end of 
the actual data block. 

The second format operation which would have to be 
performed in dliis hypothetical transfer wodd be a convetr 
sion from the padced format necessary, for transfer over 
network 14 to die format used by the applicatton 18 and the 
host computer IZ 

Format operations are performed by die forms-manager 
moddes of the communications interface. For example, the 
first format operation in the hypotheticd transfer wodd be 
performed by the fonns-manager modide 86 in HO. 1, while 
the second format opo^on in the hypotheticd transfer 
wodd be performed by the forms-manqger modde in the 
data>exch^ge component 88. 

> Referring to FIG. 8, there is shown a flowchart of the • 
opoations performed by the forms-manager modules in. 
performing format opmtions. Further detafls regarding the 
various fonctiond ccqpabilides of the routines in the forms- 
manager modules of the communications interface will, be 
found in the fonctiond specifications for the various library 
routines of the commudcations interface included herein. 
The process of FIG. 8 is implemented by the software 
programs in the forms-manager moddes of the data-ex- 
change components in the communications inter&ce accord- 
ing to die teadnngs of the inverdon. Hie first stq) is to 
leodve a format conversion call fiom either the appUcadon- 
or from anodier module in the conmumications interface. 
TMs process is symbolized by Mode 90 and the pathways 92 
and 94 in FIG. 1. Hie same type cdl can be made by the 
application 18 or communications component 96 for the 
host computer 12 in FIG. 1 to the forms-manager modde in 
the data-exdiange component 88, since this is a standard 
functiond c^)d)ility or 'tool" provided by the communica- 
tion interface of the invention to all cUent applications. 
Every client ^iplication will be linked to a communicaticm 
interface like interface 20 in FIG. L 

Typically, format conversion calls firom the communica- 
tion components such as modules 30 and 96 in FIG. 1 to the 
forms-manager module will be from a service disdpUne 
modde which is charged with the task of sending a form in 
format 1 to a fordgn application which uses format 2. 
Another likely scenario for a format conversion call firpm 
another modde in the commumcation interface is when a 
service disdpline has recdved a form from another appli- 
cation or service uiiich is in a fordgn format and wMdi 
needs to be converted to the format of the dient application. 

The format conversion cdl will have parameters associ- 
ated with it which are given to the forms manager. These 
parameters specify both the "firom" format and the "to** or 
"target" format 

Block 98 represents the process of accessing an appro- 
priate target fonnat-spedfic table for the spedfied conver- 
sion, i.e., the spedfied **from" format and the specified 
format will have a dedicated table that gives details regard- 
ing the appropriate target format class for each primitive 
*from" format class to accomplish the conversion. There are 
two tables which are accessed sequentially during every 
formal conversion operation in the preferred embodiment In 
dteniative embodim^, diese two tables rnay be combined. 
Examples of the two td>]es used in die preforred enibodi- 
ment are shown in FIGS. 9, 10 and 11. FIG. 9 shows a 
spedfic fonnat conversion table for converting from DEC 
machines to X.409 format FIG. 10 shows a format-spedfic 
conversion table for converting firom X.409 format to IBM 
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machine fonnat FIG. 11 shows a general conversion pro- 
cedures table identifying the name of the conversion pro- 
gram in the communications inteiface lihraiy which per- 
forms the particular conversion for each "from''-"to" format 
pain 5 

The tables of FIGS. 9 and 10 probably would not be the 
only tables necessary for sending a form &om the applica- 
tion 16 to the application 18 in FIG. 1. Hiere may be further 
fiormat-specific tables necessary for conversion fiom ^pli- 
cation 16 format to DEC machine format and for oonvenion iq 
from IBM machine format to application 18 format How- 
ever, the general concept of the format conversion process 
implemented by the forms-manager modules of the com- 
munications interface can be explained with lefierence to 
HGS. 9, 10 and 11. ^5 

Assume that the first conversion necessary in the process 
of sencting ^a form from application 16 to. application 18 is a 
conversion from DEC machine fonnat to a packed format 
suitable for transmission over an ETHERNET^" network. In 
this case, the format conversion call received in step 90 20 
would invoke processing by a software routine in the 
forms-manager module which would perfionn the process 
^mbolized by block 98. 

In this hypothetical example, the q>propiiate format- 
qpecific table to access by this routine would be determined 2S 
by the ''fiom*' format and "to** format parameters in the 
original format conversion call received by block 90. This 
would cause access to the table shown in FIG. 9. Hie format 
conversion call would also identify the address of the form 
to be converted. 30 

The next step is symbolized by block 100. This step 
involves accessing the form identified in the original fonnat 
conversion call and searching through the form to find the 
first field containing a primitive class of fonru In c^r 
words, the record is searched until a field is found storing 
acnial data as opposed to another constructed form having 
subfields. 

In the case of the form shown in FIG. 6, the first field 
storing a primitive dass of form is field 4Z The "fin>m'* ^ 
oohunn of the table of HG. 9 would be searched using the 
dass number 10 undl the iqipropriate entry was found. In 
this case, the entry for a "from" dass of 10 indicates that the 
format spedfied in the dass definition for primitive dass 25 
is the 'W* format This process of looking up the ''to'* fonnat 
using the "&om" fonnat is symbolized by blodcl02 in FIG. 
8. The table shown in Fid. 9 may be "Wlwired" into the 
code of the routine which peifiarms the step syrnbolized by 
block 102. 

Alternatively, the table of FIG. 9 may be a database or 50 
other file stored somewhere in the network file system 24 in 
FIG. 1. In such a case, the routine performing the step 102 
in FIG. 8 would know the netwodc address and file name for 
the file to access for access u> the table of FIG. 9. 

Next, the process symbolized by blodc 104 in FIG. 8 is 55 
performed by accessing the general conversion procedures 
table shown in FIG. 11. This is a table which identifies the 
conversion program in the forms manager which performs 
the actual work of converting one primitive class of form to 
another primitive class of form. This table is organized with 60 
a single entry for every "from**— '^o" format pain Each 
entry in the table for a "firom**— "to** pair inchides the name 
of the conversion routine which does the actual work of the 
conversion. The process symbolized by block 104 comprises 
the steps of taking the "from" — "to" pair determined from 65 
access to the format-spedfic conversion table in step 102 
and searching the entries of the general conversion proce- 
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dures table until an entry having a "from"— "to** match is 
found. In this case, the third entry from the top in the table 
of FIG. U matches the "^from**— "to** format pair found in 
the access to FIG. 9. Hiis entry is read, and it is determined 
that the name of the nnitine to perform this conversion is 
ASCn^jiiwisK. Qn many embodiments, the memory 
address of the routine, opposed to the name, would be stored 
hi the table.) 

Block 106 in FIG. 8 symbolizes the process of calling the 
conversion program id^tified by step 104 and performing 
this conv^ion routine to change the contents of the fidd 
sdected in step 100 to the "to" or target format identified in 
step 102. In the hypothetical example, the routine ASCII_ 
ETHER would be called and performed by step 106. The call 
to this routine would deliver the actual data stored in the 
field sdected in the process of step 100, ix., fidd 42 of the 
instance of a form shown in FIG. 6, such that the text-string 
"U.S. Open" would be converted to a packed EIHER- 
NET™ fonnat. 

Next, the test of blodc 108 is performed to det^nune if all 
fields containing primitive dasses of forms have been pro- 
cessed. If they have, then fonnat conversion of the form is 
completed, and the fonnat conversion routine is exited as 
symbolized by block 110. 

if fields containing primitive classes of forms remain to be 
processed, then the process symbolized by block 112 is 
performed This process finds the next fidd containing a 
primitive class of form. 

Thereafter, the processing steps symbolized by blocks 
102, 104, 106, and 108 are performed until all fidds con- 
taining primitive dasses of forms have been converted to the 
appropriate "to" fbnnaL 

As noted above, the process of searching for fields con- 
taining primitive dasses of forms proceeds serially through 
the form to be converted. If the next field encountered 
contains a form of a constructed dass, that class of form 
must itself be searched until the first field therdn with a 
primitive dass of form is located. Tins process continues 
through all levels of nesting for all fields until all fidds have 
been processed and all data stored in the form has been 
converted to the appropriate format. As an example of how 
this works, in the form of FIG. 6, after processing the first 
field 42, the process symbolized by block 112 in FIG. 8 
would next encounter the fidd 44 (fields will be referred to 
by the block of data that contain the class ID for the form 
stored in that field although the contents of the field are both 
the class ID and the actual data or the fields and subfidds of 
the form stored in that field). Note that in the particular class 
of form represented by FIG. 6, the second fidd 44 contahis 
a constructed form comprised of several subfields. Process- 
ing would then access the constructed form of class 1000 
which is stored by the second fidd and proceeds serially 
through this constructed form undl it locates the first fidd 
thereof which contains a form of a primitive dass. In the 
hypotheticd example of FIG. 6, the first field wodd be the 
subfield indicated by the class number 11 at 52. The process 
symbolized by blodc 102 would then look up class 11 in the 
"firom" column in the table of FIG. 9 and determine that the 
target format is spedfied by the class definition of primitive 
class 15. Hiis "from*— 'to" pair 11-15 would then be 
compared to the entries of the table of FIG. 11 to find a 
matching entry. Thereafter, the process of block 106 in FIG. 
8 would perform the conversion program called Floatl_ 
ETHER to convert the block of data at 60 in FIG. 6 to the 
appropriate ETHERNETtm packed format The process then 
would continue through all levels of nesting. 
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Referring to FIG. 12, there is shown a flowchart for a 
typical semantic-dependent operation. Semantic-dependent 
operations allow decoupling of applications by allowing one 
application to get the data in a particular field of an instance 
of a form generated by a foreign application provided that 5 
the field name is known and the address of the form instance 
is known. Hie coonnunications interface according to the 
teachings of the invention receives 8eniantic-dq)endent 
operation xequests from client ^plications in the fbnn of 
Oet^Held rails in the prefiened embodiment where all 10 
processes use the same field names for data fields which 
mean the same thing (regardless of the organization of the 
fiorm or the data reprcsentatioii of the field in the form 
generated by the foreign process). In alternative embodi- 
ments, an aliasing or synonym table or data base is used. In IS 
such embodiments, the GetJRcld call is used to access the 
^synonym table in the class manager and looks for all 
^synonyms of the request^ field mune. All field names which 
are synonyms of the requested field name are returned. Tb& 
dass manager then searches the dass definition for a match 20 
with either the requested field name or any of the synonyms 
and retrieves the field having the matdung fidd name. 

Returning to consideration of the prefened embodiment, 
such Get_Field calls may be made by dient appUcaticms 
direcfiy to the forms-class manager modules such as the 
module 122 in FIG. 1, or they may be made to die conmni- 
nications components or forms-manager modules and trans- 
ferred by these modules to the forms-dass manager. The 
farms-dass manager creates, destroys, manipulates, stores 
and reads focnHdass definitions. 30 

A Gct_Fidd call delivers to the foims-dass manager the 
address of the form involved and the name of the fidd in the 
form of interest The process of receiving such a request is 
symbolized by block 120 in FIG. 12. Block 20 also sym- 
bolizes the process by which the dass manager is given the 
dass definition either programmatically, Le., by the request- 
ing application, or is told the location of a data base where 
the class definitions including the class definition for the 
fonn of interest may be found. There may be several 
databases or files in the network file system 24 of FIG. 1 ^ 
wherein class definitions are stored. It is only necessary to 
give the forms-class manager the location of the particular 
file in which the dass definition for the form of interest is 
stored 

45 

Next, as symbolized by. blodc 122, the dass-manager 
module accesses the dass definition for the form dass 
identified in the original caU. 

The dass manager ihen seances the class definition fidd 
names to find a match for the field name given in the angina] 50 
call. This process is symbolized by block 124. 

After locating the field of interest in the class definition, 
the dass manager returns a relative address pointer to the 
fidd of interest in instances of forms of this dass. This 
process is symbolized by block 126 in FIG. 12. The relative ss 
address pointer retuined by the dass manager is best under- 
stood by reference to FIGS. 2, 4 and 6. Suppose that the 
Implication which made the Get^Hdd call was mterested in 
determining the age of a particular player. The Get_Field 
request would identify the address for the instance of the 60 
form of dass 1002 for player Blackett as illustrated in FIG. 
6. Also indtided in the GeLJndd request- would be the 
name of the fidd of interest, ix., **age". The class manager 
would then access the instance of the form of mterest and 
read the dass number identifying the particular dass 6S 
descriptor or dass definition which q>plied to this class of 
forms. The dass manage would then access the dass 
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descriptor for dass 1002 and find a dass definition as shown 
in FIG. 4. The dass manager would then access the dass 
definitions for each of the fields of dass definition 1002 and 
would compare the fidd name in the original Get_JneId 
request to the field names in the various class definitions 
which make up the dass definition for dass 1002. In other 
words, the dass manager would compare the names of the 
fields in the dass definitions for classes 10, 1000, and 1001 
to the field name of interest, "Age". A match would be found 
in the dass definition for dass 1000 as seen firom FIG. 2. For • 
the particular record format shown in FIG. 6, the "Age" field 
would be the block of data 62, which is the tenth block of 
data in fiom the start of the record. Hie class manager would 
then remm a relative address pointer of 10 in block 126 of 
FIG. 12. This relative address pointer is returned to the client 
application which made die origmal Get_Ineld call^ The 
dient application thea issues a Get_Data caU to the forms- 
manager module and delivers to the foims-manager module 
the relative address of the desired field in the particular 
instance of the fonn of interest The forms-manager module 
nmst also know the address of the instance of the form of 
intnest which it wfll already have if the original Get;_Hdd 
call came through the forms-manager mnrf^ilp and was 
transfened to the farms-dass manager. If the forms-manager 
nxHlnle does not have the address of the particular instance 
of the form of interest, tbsn the fmos tiiftn«g«*r will request 
it from the client application. After receiving the Get_J>ata 
call and obtaining tl^ rdative address and the address of the 
instance of the form of interest, the fonns manager will 
access this instance of the form and access the requested data 
and return it to the client ^plication. This process of 
recdving the Get^Data call and returning the appropriate 
data is symbolized by block 128 in FIG. 12. 

Normally, dass-manager modules store the dass defini- 
tions needed to do semantic-dependent operations in RAM 
of the host machine as dass descriptors. Qass definitions are 
the spedfication of the semantic and fonnation information 
that define a class. Qass descriptors are memoiy objects 
which embody the dass definition. Class descriptors are 
stored in at least two ways. In random access memory 
(RAM), dass descriptors are stored as fbrms in tibe format 
native to the machine and dient application that created the 
dass definidon. Class descriptors stored on dBsk or tape are 
stored as ASCD strings of text 

When the dass-manager module is asked to do a seman- 
tic-dependent operation, it searches through its store of class 
descriptors in RAM and determines if the appropriate class 
descriptor is present If it is, this class descriptor is used to 
perform the operation detailed above with reference to FIG. 
12. If the appropriate dass descriptor is not preset, the class 
manager must obtain it This is done by searching through 
known files of dass descriptors stored in the system files 24 
in HG. 1 or by making a request to the foreign application 
that created the class definition to send the dass definition to 
the requesting module. The locations of the files storing 
dass descripton are known to the client applicadons, and 
the class-manager modules also store these addresses. Often, 
the request for a semantic-dependent opemtion includes the 
address of the file where the aj^priate dass descriptor 
may be found. If the request does not contain sudi an 
address, the dass manager looks through its own store of 
dass descriptors and through the files identified in records 
stored by the dass manager identifying the locations of 
system dass descriptor files. 

If the class manager asks for the dass descriptor from the 
fordgn application that generated it, the foreign applicafion 
sends a request to its class manager to send the appropriate 
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class descriptor over the network to the requesting dass 
manager or the requesting module. The class descriptor is 
then sent as any other form and used by the requesting dass 
manager to do the requested semantic-dq)endent operation. 

If the class manager must access a file to obtain a class ^ 
descriptor, it must also convert the packed ASCH represen- 
tation in which the class descriptors are stored on disk or 
tape to the format of a native form for storage in RAM. This 
is done by parsmg the ASCH text to separate out the various 
field names and specifications of the field contents and the 10 
class numbers. 

FIGS. 13A and 13B illustrate, respectively, a class defi- 
nition and the stmcture and organization of a class descriptor 
for the class definition of FIG. 13A and stored in memory as 
a form. The class definition given in FIG. 13A is named 
Person_CIa8s and has only two fields, named last and first 
Eacliofthesefieldsis8pecifiedtostorea'20-chaiact6rASCn — 
string. 

FIG. 13B has a data block 140 which contains 1021 
indicating that the form is a constructed form having aclass 
number 1021. The data block at 142 indicates that the form 
has 3 fields. The first field contains a primitive class speci- 
fied to contain an ASCII string which happens to store the 
class name, Person_Class, in data block 146. The second 
field is of a primitive class assigned the number 2, data blodc 
148, which is specified to contain a boolean value, data 
block 150. Semandcally, the second field is defined in the 
class definition for dass 1021 to define whether the form 
class is primitive (true) or constructed (false). In this case, 
data block 150 is false indicating that dass 1021 is a 
constructed dass. The third field is a constructed dass given 
the dass number 112 as shown by data block 152. The class 
definition for class 1021 defines the third fidd as a con- 
structed dass form which gives the names and spedfications 
of the fields in the class definition. Data block 154 indicates 
that two fidds exist in a class 112 form. The first fidd of 
dass 112 is itself a constructed class given the dass number 
150, data block 156, and has two subfields, data block 158. 
Tb& first subfield is a primitive dass 15, data block 160, 
whidi is spedfied in the dass definition for class 150 to 
contain the name of the first field in class 1021. Data block 
162 gives die name of the first fidd in dass 1021. The 
second subfield is of primitive class 15, data block 164, and 
is specified in the dass definition of dass 150 (not shown) 
to contain an ASCII string which specifies the rqxresenta- 
tion, data block 166, of the actual data stored in the first fidd 
of class 1021. The second field of dass 112 is specified in the 
dass definition of dass 112 to contain a constructed form of 
dass 150, data block 168, which has two fields, data block 
170, which give the name of the next field in dass 1021 and 
spedfy the type of representation of the actual data stored in 
this second field. 



DATA DISTRIBUTION AND SERVICE 
PROTOCOL DECOUPLING BY 
SUBJECT-BASED ADDRESSING AND THE USE 
OF SERVICE DISCIPLINE PROTOCOL LAYERS 

Referring to FIG. 14, there is shown a block diagram of 60 
the various software modules, files, networks, and comput- 
ers whidi cooperate to implement two important forms of 
decoupling. These forms of decoupling are data distribution 
decoupling and service protocol decoupling. Data distribu- 
tion decoupling means freeing client applications from the 65 
necessity to know the network addresses for servers provid- 
ing desired services. Thus, if a particular application needs 
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to know information supplied by, for example, the Dow 
Jones news service, the client application does not need to 
know which servers and which locations are providing data 
from the Dow Joites news service raw data feed 

Service protocol decoupling means that the client appli- 
cations neod not know the particular communications pro- 
tocols used by the servers, services or other applications 
with which exchanges of data are desired. 

Data distribution decoupling is implemented by the com- 
munications module 30 in FIG. 14. The communicadons 
component is comprised of a Ubrary of software routines 
which implement a subject m^per 180 and a plurality of 
service disdplines to implement subject-based addressing. 
Service disdplines 182, 184 and 186 are exemplary of the 
service disdplines involved in subject-based atkfaessing. 

Subject-based addressing allows services to be modified 
or replaced by alternate services providing infor- 
liiation witibbut impacting the information consumers. This 
decoupling of the information consumers firom information 
providers permits a higher degree of modularization and 
flexibility than that provided by tracfitional service-oriented 
models. 

Subject-based addressing starts with a subscribe call 188 
to the subject mapper 180 by a client application 16 running 
on host computer 10. The subscribe coll is a request for 
information regarding a particular subject Stq)pose hypo- 
thetically that the particular subject was equityJBM jiews. 
This subscribe call would pass two parameters to the subject 
mapper 180. One of these parameters would be the subject 
equity JBM.news. The other paramet^ would be the name of 
a callback routine in the client application 16 to which data 
regarding the subject is to be passed. The subscribe call to 
the subject mapper 180 is a standard procedure call. 

The purpose of the subjea nukpper is to determine the 
network address for services which provide information on 
various subjects and to invoke the BppmpnaiB service dis- 
dpline routines to establish communications with those 
services, lb find the location of the services whidi provide 
infarmadon regarding the subject in the subscribe call, the 
subject mapper 80 sends a request symbolized by Une 190 to 
a directory-services component 19Z The directory-services 
component is a separate process running on a computer 
coupled to die network 14 and m fact may be running on a 
separate computer or on the host computer 10 itself. The 
directory-services routine maintains a data base or table of 
records called service records which indicate which services 
supply information on which subjects, where those sovices 
are located, and the service disdplines used by those ser- 
vices for communicatiotL The directory-services componoit 
192 receives the request passed from the subject mapper 180 
and uses the subject parameter of that request to search 
through its tables for a match. That is, the directory-services 
component 192 searches through its service records until a 
service record is found indicating a particular service or 
services which provide information on the desired subject. 
This service record is then passed back to the subject mapper 
as symbolized by line 194. The directory-services compo- 
nent may find several matches if multiple services supply 
information regarding the desired subjecL 

Hie service record or records passed back to die subject 
mapper symbolized by line 194 contain many fields. TWo 
required fields in die service records are die name of the 
service which provides information on the desired subject 
and the name of the service disdpline used by that service. 
Other optional fidds which may be provided are the name of 
the server upon which said service is running and a location 
on the network of that server. 
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Generally, the directoty-sa>dce8 component will deliver 
all the semce records for which there is a subject map, 
because there may not be a complete overlap in the infor- 
mation provided on the subject by all services. Further, each 
service will run on a separate server which may or may not 5 
be coupled to the client application by the same netwode If 
such multiplicity of network paths and services exists, 
passing all the service records with subject matter matches 
back to the subject mapper provides the ability for die 
communications interface to switch networks or switch 
servers or services in the case of failure of one or more of 
these items. 

As noted above, the subject mapper 180 functions to set 
up comnumications with all of the services providing infor- 
mation on the desired subject If multiple service records are 
passed back from the directory-services module 192^ then 
the subject mapper 180 will setup communications with all 
-of these services. 

Upon lecdpt of the service records, the subject mapper 
will call each identified service discipline and pass to it die 20 
sulrject and the service record i^ficable to that service 
discipline. Although only dute service disciplines 182» 184 
and 186 are shown in HQ. 14, there may be many moie than 
three in an actual system. 

In the event that the directory-services component 192 25 
does not exist or does not find a match, no service records 
will be returned to the subject m^per 180. In such a case, 
the subject mapper will call a def^t service discipline and 
pass it and the subject and a null record. 

Bach service discipline is a software module which con- 30 
tains customized code optimized for comimmication with 
the particular service associated with that service discipline. 

Each service discipline called by the subject mapper 180 
examines the service records passed to it and detennines the 
location of the service with which conununications are to be ^ 
estabUshed. In the particular hypothetical example bemg 
considered, assume that only one service record is returned 
by the directory-services module 192 and that that service 
record identifies the Dow Jones news service running on 
server 196 and further identifies service disdpline A at 182 ^ 
as the q)propriate service discipline for commurucations 
with the Dow Jones news service on server 196. Service 
disc^line A will then pass a request message to server 196 
as symbolized by line 198. This request message passes the 
sulyject to the service and may pass all or part of tiie service 
record. 

The server 196 processes the request message and deter- 
mines if it can, in fact, supply information regarding the 
desired sulject It then sends back a reply message symbol- en 
izedbylinelOO. ^ 

Once communications arc so established, the service 
sends all items of information pertaining to the requested 
subject on a continual basis to the appmpnatc service 
discipline as symbolized by path 202. In the example chosen 55 
here, the service running on server 196 filters out only those 
news items which pertain to IBM for sending to service 
discipline at 182. In other embodiments, the server may pass 
along all information it has without filtering this information 
by subject The communications component 30 then filters 50 
out only the requested inf(Hmation and passes it along to the 
requesting application 16. In some embodiments this is done 
by the daemon to be described below, and in other embodi- 
ments, it is done elsewhere such as in the information or 
service layers to be described below. ^5 

Each service disdpline can have a different behavior. For 
example, service discipline B at 184 m^ have the following 
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behavior. The service running on server 196 may broadcast 
an news items of the Dow Jones news service on the 
network 14. All instances of service discipline B may 
monitor the network and filter out only those messages 
which pertain to the desired subject M^y different com- 
munication protocols are possible. 

The service discipline A at 182 receives the data trans- 
mitted by the service and passes it to the named callback 
routine 204 m die client application 16. CThe service disci- 
pline 182 was passed the name of the callbadc routine in the 
initial message from the mapper 180 symbolized by Une 
18L) The named callback routine then does whatever it is 
programmed to do with the information regarding the 
desired subject 

Data will continue to flow to the named callback routine 
204 in this manner until the client application 16 expressly 
issues a cancel^command to die sjibjec^ mapper 180. The 
subject mapper 180 keeps a record of all subscriptions in 
existence and compares the cancel conunand to the various 
subsoiptions which are active. If a match is found, the 
appropriate service discipline is notified of tiie cancel 
request, and this service discipline then sends a cancel 
message to the ^propriale server. The sCTvice then cancels 
transmission of further data regardiiig that subject to the 
service discipline which sent the cancel request 

It is also possible for a service discipline to stand alone 
and not be coupled to a subject mapper. In this case the 
service discipline or service disciplines are linked directly to 
the application, and subscribe calls are made directiy to the 
service discipline. The difference is that the application must 
know the name of the service supplying the desired data and 
the service discipline used to access the service. A database 
or directory-servioes table is tiien accessed to find the 
netwoik address of the identified service, and communica- 
tions are established as defined above. Aldiough this soft- 
ware architecture does not provide, data distribution decou- 
pling, it does provide service piotocc^ decoupling, Uiereby 
freeing the application ficom the necessity to know the details 
of die communications interface with the service with which 
data is to be exchanged. 

More details on subject-based addressing subscription 
services provided by the communications interface accord- 
ing to the teachings of the invention are given in Section 4 
of the communications intoface specification given belowi 
The preferred embodiment of the communications interface 
of die invention is constructed in accordance widi that 
specification. 

An actual subscribe function in the preferred embodiment 
is done by perfomti^g the nB^Consume^Cieate lifaraty . 
routine described in Section 4 of die spedfication. The call 
to TlB_Consuine^Create includes a property list of param- 
eters which are passed to it, one of which is the identity of 
the callback routine specified as My_MeBsage._J]andler in 
Section 4 of die ^jecificatioa 

In the specification, the subject-based addressing sub- 
scription service function is identified as TIBINFO. Hie 
TIBINFO interface consists of two libraries. The first library 
is called TIBINFO_CONSUME for data consumers. The 
second litary is called TIBINFO^PUBLISH for data pro- 
viders. An application includes one library or the other or 
both depending on whether it is a consumer or a provider or 
both. An application can simultaneously be a consumer and 
a provider. 

Referring to FIG. 15, there is shown a block diagram of 
the relationship of the conununications interfiaoe accofding 
to the teachings of the invention to the applications and the. 
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network that couples these applications. Blocks having 
identical reference numerals to blocks in FIG. 1 provide 
similar functional capabilities as those blocks in FIG. 1. Hie 
block diagram in RG. 15 shows the process architecture of 
the prefOTed embodiment The software anchitectiue corre- 
sponding to the process architecture given in FIG. 15 is 
shown in block form in FIG. 16. 

The software architecture and process architecture 
detailed in FIGS. 15 and 16. lespectively, fepscsents an 
alternative embodiment to the embodiment described above 
with reference to FIGS. 1-14. 

Referring to FIG. 15, the oommunications component 30 
of FIG. 1 is shown as two sq»rate foncdonal blocks 30A 
and SOB in HQ. 15. ThA Is, the functions of the commu- 
nications conqNment 30 in FIG. 1 are split in the process 
architecture of FIG. 15 between two functional Mocks. A 
communications library 30A is lirdced with each dii&at 
'"'application 16, and a'bacVerid commimicaHons ^daemon 
process 30B is linked to tlie network 14 and to the commu- 
mcation library 30A. There is typically one communication 
daemon per host processor. Tliis host processor is shown at 
230 in FIG. 15 but is not shown at all in FIG. 16. Note that 
in HG. 15, unlike the simation in HG. 1, the diem sppU- 
cations 16 and 18 are both running on the same lu>st 
processor 230. Each client application is Hiiked to its own 
copies of the various library programs in the communication ^ 
libraries 30A and 96 and the form library of the data- 
exchange components 32 and 88. lliese linked libraries of 
pr ogr am s share a common communication daemon 30B. 

The communication daemons on the various host proces- 
sors cooperate among themselves to insure reliable, efficient ^ 
communication between machines. For subject addressed 
data, the daemons assist in its efBdent transmission by 
providing low-levd system support for filtering messages by 
subject. The communication daemons implement various 
conununication protocols described below to implement 
fault tolerance, load balancing and network effidency. 

The communication library 3QA performs numerous func- 
tions associated with each of the plication-oriented com- 
munication suites. For exanq)le, the comnmnication library 
translates subjects into efficient message headers ftat are 
more compact and easier to chedc than ASCH subject 
values. The oommunications library also service 
requests into requests targeted for particular service 
instances, and monitors the status of those instances. 

The data-exchange component 32 of the communications 
interface according to the teachings of the invention is 
iiiq)lemented as a library called the 'fiorm library.** This 
lilHBry is linked with the dient application and provides all 
the core functions of the data-exchange component Hie 
form library can be linked independendy of the conununi- 
cation library and does not require the communication 
daemon 30B for its operatioa 

The communication daemon serves in two roles. In the 
subject-based addressing mode described above where the 
service instance has been notified of the subject and the 
network address to which data is to be sent pertaining to this 
subject, the communication daemon 30B owns the network 
address to which die data is sent. This data is then passed by 
the daemon to the communication library bound to the dient 
apidication, which in turn passes the data to the appropriate 
callback routine in the dient application. In another mode, 
the communication daemon filters data coming in from the 
network 14 by subject when the service instances providing 
data are in a broadcast mode and are sending out data 6S 
regarding many different subjects to all daemons on the . 
network. ^ 
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The blocks 231. 233 and 235 in FIG. 15 represent the 
interface functions which are implemented by the programs 
in the communication library 30A and the form library 32. 
The UBINFO interface 233 provides subject-based address- 
ing services by the communication paradigm known as the 
subscription caU. In this paradigm, a data consumer sub- 
scribes to a service or subject and in return receives a 
contiimous stream of dam about the service or subject untiil 
the consumer explidtly terminates the subscription (or a 
failure occurs). A subscription paradigm is well suited to 
real-time appUcations that monitor dynamically dianging 
values, such as a stock price. In contrast, the more traditional 
request/reply coxxmnmication is ill suited to such real-time 
applications, since it requires data consumers to '*pol]" data 
providers to learn of changea. 

The interface 235 defines a programmatic interface to the 
protocol suite and service comprisii^ the Market Data 
Subscri|>tion Service (MD5S) 8ub-ooi^)onent 234 in FIG. ^ 
16. This service disdpline will be described more fidly later. 
The RMDP interface 235 is a service address protocol in that 
it requires the ciient application to know the name of the 
.service with wiucfa data is to be exchanged. 

In HG. 16 there is shown the software architecture of the 
systenL A distributed communications component 232 
includes various protocol engines 237, 239 and 241. A 
protocol engine encapsulates a communication protocol 
which interfaces sendee disdpline protocols to the particular 
network protocols. Each pn)tocol engine enc^sulates all the 
logic necessary to establish a highly reliable, highly ef&dent 
communication connection. Each protocol engiae is tuned to 
spedfic network properties and spedfic applications prop- 
erties. The protocol engines 237, 239 and 241 provide a 
generic communication interface to the client applications 
such as {plications 16 and 18. This frees these applicaticsis 
(and die programmers that write them) from the need to 
know tiie spedfic network or transport layer protocols 
needed to communicate over a particular network configu- 
ration. Further, if the network configuration or any of the 
network protocols are changed such as by addition of a new 
local area network, gateway etc. or switching of transport 
layer protocols say from DECNET™ to TCP/IF™, the 
application programs need not be changed. Such changes 
can be accommodated by the addition, substimtion or alter- 
ation of the protocd entgines so as to accommodate die 
change. Since these protocol engines are shared, there is less 
effort needed to change the protocol engines than to change 
an the applications. 

The protocol engines provide protocol transparency and 
communication path transparency to the applications 
thereby freeing these q)plications from the need to have 
code which deals with all these details. Further, these 
protocol ei^gines provide network interface transparency. 
fO^ The jnotocden^nes can also provide value added ser- 
vices in some embodiments by implementing reliable com- 
munication protocols. Such value added services indude 
reliable tosadest and reliable point to point communications 
as well as Reliable Multicast*"*^ commuiucations where 
communications are switched from rdiabie broadcast to 
reliable point to point when the situation requires tius 
change for efSdency. Farther, the protocol engines enhance 
broad^sToperations where twcuor^moxe..^^|^tio3S_are 
requesting cbta.Q D_a subject b y recdvi^ data directed to th e 
first requesting applicat iQn.and-passineiralong to_tiffi^^ier 
reqiigsting^p plications._ Prior art broadcast software does 
not have this c^)ability. 
The protocol engines also support efBcient subject based 

addres^ by filtering messages r ecdved on the networic by 
^ ^111 1 
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subject In this way, only data on the requested subject gets 
passed to the callback routine in the re questing applicat ion. 
In the piefeixed embodinient, the protocol engines coupled 
to the producer applications or service instances tilts' the 
data by subject before it is placed in the network thereby 5 
conserving networic bandwidth, input/outpuT'processor 
bandwidth and overhead processing at the receiving ends of 

com munication links. ' ■ , 

^ The distributed communication component 232 (hereafter 
^ DCQ in FIG. 16 is structured to meet several important 10 
objecdves. First, the DCC {Hovides a simple, stable and 
uniform comnmmcadon model. This provides several ben- 
efits. It shields progfarnmers from the complexities of: the 
distri buted envinin i^t; locatinga taig^ process; establish- 
. iiig communications with this target process; and determin- ^5 
ing when something has gone awiy. AH these tasks are b est 
riniif. ^yy rnpahl^ ftQw munications infrastructure and n ot by 
the progiammei: Second* the DCX! ' reduces development 
time not only by increasing programmer productivity but 
also by simplifyLag the integration of new features. Hnally, 20 
it enhances configurability by eliminating the burden on 
applications to know the pl^sical distrihutiDii.on4h&-net- 
work o fother com ponents. Ibis prevents progranuncrs from 
building dependencies in their code on particular physical^ 
configurations which would complicate later reconfigura- 2s 
tions. 

Another important objective is the achievement of port- 
ability through erx^sulation of important system structures. 
This is important when rmgrating to a new hardware or 
software environment because the client applications, are 30 
in sulate dJ[;^i^gg8 port and accg sj yotocols that na y be 
changiag. By isolating the required changes in a small 



portion of the system (the DCX:). the a gplications can be 
ported^yinjiaBon ^nged and the investtneni ufthe g>p li- 
cat ion s oftwate-is-jwotected 

E£5ciency is achieved by the DCX: because it is coded on 
top of less costly "connectionless" transport protocol in 
standard protocol suites such as TCP/IP and OSL The DC!C 
is designed to avoid the most costly proUem in protocols, 
Le., the proliferation of data "copy* operations. 

The DCC achieves these objectives by implementing a 
layer of services on top of the basic services provided by 
vendor supplied software. Rather than re-inventing basic 
functions liiee reliable data transfer or flow-control mecha- 
nisms, the DCC shields applications from the idiosyncradcs 
of any particular operating system. Examples include the 
hardware oriented interfaces of the MS-D(>S environment, 
or the per-process file descriptor limit of UNIX. By provid- 
ing a single unified communication toll that can be easily 
replicated in many hardware and software environments, the 
DCX: fulfills the above objectiveis. 

The DCC implements several different transmission pro- 
tocols to support the various interaction paradigms, fault- 
tolerance requirements and performance requirements ^ 
imposed by the service discipline protocols. Two of the more 
interesting protocols arc the reliable broadcast and intelli- 
gent multicast protocols. 

Standard broadcast protocols are not reliable and are 
unable to detea lost messages. Hie DCC reliable broadcast ^ 
protocols ensure that all operational hosts either receive each 
broadcast message or detects the loss of die message. Unlike 
many so-called reliable broadcast protocols, lost messages 
are retransmitted on a limited, periodic basis. 

The Intelligent Multicast''^ protocol provides a reliable 65 
datastieam to multiple destinations. The novel aspect of diis 
protocol is that it can switch dynamically firom point-to- 
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point transmission to broadcast transmission in order to 
optimize the ii^wo± and processor load. The switch from 
point-to-point to broadcast (and vice- versa) is transparent to 
higher-level protocols. This transport protocol allows the 
svq)port of a much larger number of consumers than would 
be possible using either point-to-point or broadcast alone. 
The protocol is built on top ofother protocols with the DCX:. 

Omently, all DCC protocols exchange daia only in dis- 
crete units, i,e., messages (in contrast to many traiisport 
protocols). The DCC guarantees that the messages ori^nat- 
ing from a single process are received in the order sent. 

The DCC contains fault tolerant message transmission 
protocols diat support retransmission in the event of a lost 
message. The DCC software guarantees "at-most-once" 
semantics with regard to message delivery and makes a best 
attempt to ensure ''exacdy-once" semantics. 
^ The DCC has no exposed interface for use by application 
programmers. 

The distributed component 232 is coupled to a variety of 
service disciplines 234, 236 and 238. The service disdi^ine 
234 has the behavior which will herein be caDed Maricet 
Data Subscription Service. This protocol allows data con- 
sumers to receive a continuous stream of fault tolerant 
of Mlures of individual data sources. This protocol suite 
I^Dvides mechanisms for administering load-balancing and 
entiUement policies. 

The MDSS service discipline is service oriented in that 
applications calling this service discipline through the 
RMDP interface must know the service that, supplies 
requested data. The MDSS service discipline does however 
si^port the subscription conmxunication pamriigm which is 
i]iq)lemented the Subject Addressed Stibsaiption.Scrvice 
(SASS) service discipline 238 in die sense that streams of 
data on a subject ^ be passed by die MDSS service 
discipline to the linked ^plicatiorL 

The MDSS service discipline ailowida^^onsumfiLappH- H 
cations to rereiye jLCQ Dtiiiuous stream of d ata, tolerant of \ 
faihSes or mdivi^ial data sources. Hzis protocol suite 234 
also provides mechanisms for load balancing and entiUe- 
ment policy administration where the.aixess<privijeg^^ a 
user or application are chec ked toinsnrc a d ata consu mer has 
a ri ght to obtain data from a p articula r scrvios! 

Two properties distinguish the MDSS service discipline 
from typcal client server protocols. Rxst, subscriptions are 
explicitiy supported whereby changes to requested values 
are automatically propagated to requesting applications. 
Secoiul client applications request or subscribe to a specific 
service (as opposed to a particuhir server and as opposed.to 
a particular subrject). T^e MDSS service discipline then 
forwards the client application request to an available serw. 
The MDSS service disdptine also monitors the server 
connection and reestablishes it if the connection fails using 
a different server if necessary. 

The MDSS service discipline implements the following 
important objectives. 

Fault tolerance is implemented by program code which 
performs automatic switchover between reduiidant services 
by supporting dual or triple networks and by utilizing die 
fault tolerant transmission protocols such as reliable broad- 
cast implemented in the , protocol engines. Recovery is 
automatic after a server failure. 

Load balancing is performed by balancing the data 
request load across all operating servers, for a particular 
service. Hie toad is automatically rebalanced when a server 
fails or recovers. In addition, the MDSS supports server 
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assignment policies that attempts to optimize the utilization 
of scarce resources such as "slots" in a page cache or 
bandwidth across an external communication line. 

Network efficiency is implemented by an intelligent mul- 
ticast protocol implemented by the distributed communica- 
tion daemon 30B in FIG. L5. The intelligent multicast 
protocol optimizes limited resources of network and I/O 
processor bandwidth by performing automatic, dynamic 
switchover from point to point communication protocols to 
broadcast protocols when necessary. For example, Tfelerate 
page 8 data may be provided by point to point distribution 
to the first five subscribers and then switch all subscribers to 
broadcast distribution when the sixth subscriber appears. 

The MDSS service discipline provides a simple, easy-to- 
use application development inter&ce that masks most of 
the complexity of programming a distributed system, indud- 
ing locating servers, establishing communication connec- 
' tions; reacting to failures and recoveries and load balandog. 

The core functions of die MDSS service discipline are: 
get, halt and derive. The "get" call &om a client application 
establishes a fault-tolerant connection to a server for the 
specified service and gets the current value of the specified 
page or data element Hie connection is subscription based 
so that updates to the specified page are automatically 
forwarded to the client plication. "Half* stops the sub- 
scription. '*Drive" sends a modifier to the service that can 
potentially change the subscriptioa 

The MDSS service discipline is optimized to support page 
oriented services but it can support distribution of any type 
data. 

The service discipline labeled MSA, 236, has yet a 
different behavior. The service discipline labeled SASS, 238. 
supports' subject-based address subsoiption services. 

The basic idea behind subject based addressing and the 
SASS service discipline's (hereafter SASS) iix^ilementation 
of it is straightforward. Whenever an q)plication requires 
data, especially data on a dynamically changing value, the 
cq)plication singly subscribes to it by specifying the ^pro- 
priate subject Tlie SASS then maps this subject request to 
one or more service instances providing information on this 
subject The SASS then makes the appropriate communica- 
tion connections to all die selected services through the 
appropriate one or more protocol engines necessary to 
communication with the servicer or servers providing the 
selected service or services. 

Through the use of subject based addressing, infonnation 
consumers can request information in a way that is inde- 
pendent of the plication producing the information. 
Hence, the producing ^plication can be modified or sup- 
planted by a new application providing the same information 
without affecting the consumers of the information. 

Subject based addressing greatly reduces the complexities 
of programming a distributed application in three ways. 
E^t, the ^plication requests information by subject as 
opposed to by server or service. Specifying infonnation at 
this high level removes the burden on applications of 
needing to know the cmrent network address of the service 
instances providing the desired infonnation. It further 
relieves the application of the burden or knowing all the 
details of the communication protocols to extract data from 
the appropriate service or services and the need to know the 
details of the transport protocols needed to traveree the 
networiL Further, it insulates the client applications from the 
need for programming changes when something else 
changes like changes in die service providers, e.g., a change 
firom IDN to Ticker 3 for equity prices. All data is provided 



through a single, uniform interface to client applications. A 
programmer writing a client application needing informa- 
tion from three different services need not leam three 
different service specific communication protocols as he or 
she would in traditional commuincation inodels. Finally, the 
SASS automates many of the difficult and error prone tasks 
such as searching for an appropriate service instance and 
establishing a correct commimication connection. 

The SASS service discipline provides three basic func- 
tions which may be invoked tiirough the user interface. 

"Subscribe" is the function invoked when the consiuner 
requests information on a real-time basis on one or more 
subjects. The SASS service discipline sets up any necessary 
comnmnication connections to ensure that aU da^ Timtrhing 
the given subject(s) will be delivered to the consumer 
application. The consumer can specify that data be delivered 
either asynchronously (intemipt-driven) or synchronously. 

TbcT producer service will'be'notified'of the subscription ^ 
if a registration procednre for its service has been set up. 
Hiis registration process will be done by the SASS and is 
invisible to the user. 

The "cancel" function is the opposite of "subscribe". 
When this function is invoked, the SASS closes down any 
dedicated communication chaimel and notifies the producer 
service of the cancellation if a registration procedure exists. 

Tlie "Receive" function and "callback** function are 
related functions by which ^plications receive messages 
.matching their subscriptions. Callbadts are asynchronous 
and support the event driven programming style. This style 
is well suited for appUcadons leqmring real time data 
exchange. The receive function supports a traditional syn- 
chronous interface for message receipt 

A complementary set of functions exists for a data pro- 
ducer. Also . applications can be both data producers and data 
consumers. 

Referring to FIG. 17 tiiere is shown a typical computer 
network situation in which the teachings of the invention 
may be profitably employed. The computer network shown 
is comprised of a first host CPU 300 in Houston coupled by 
a local area networic (hereafter LAN) 302 to a file server 304 
and a gateway network intercoimect circuit 306. The gate- 
way circuit 306 connects tiie LAN 302 to a wide area 
networic (hereafter WAN) 308. Vic WAN 308 couples die 
host 300 to two servers 310 and 312 providing the Quotnm 
and Marketfeed 2000 services, respectively, firom London 
and Paris, respectively. The WAN 308 also couples the host 
300 to a second host CPU 314 in (jeneva and a server 316 
in Geneva providing the Tblerate service via a second LAN 
318. Dumb terminal 320 is also coupled to LAN 318. 
(^b Typically the hosts 300 and 314 will be multitasking 
madiines, but tiiey may also be single process CPU*s such 
as computers running Uie DOS or PC-DOS operating sys- 
tems The TIB communication interface software supplied 
herewith as Appendix A embodies the best mode of prac- 
ticing the invention and is ported for a Unix based multi- 
tasking machine. To adapt the teachings of die invention to 
the DOS or other single task environments requires that the 
TB communication daemon 30B in the process architecture 
be stmctures as an interrupt driven process which is invoked, 
i.e., started upon receipt of a notification from the operating 
system that a message has been received on the network 
which is on a subject to which one of the i^lications has 
V subscribed 

fiiV\ Hie LAN's 302 and 318, WAN 308 and gateway 306 may 
each be of any conventional structure and protocol or any 
new structure and protocol developed in the future so long 
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as they axe sufiSdeotly compatible to allow data exchange 
among die remaining elements of the system, lypically^ the 
stmctuies and prot ocols used on the networks will be 
TCP/IP, DECNETTM, ETHERNET™, token ring, ARPA- 
NET and/or other digital pack or high speed private line 5 
digital or analog systems using hard wire, microwave or 
saEsUite transmission media. Various OCTIT recommenda- 
tions such as X.1, X.2, X.3, X.20, X.21, X.24. X.28. X,29, 
X25 and X.75 suggest speeds, u ser options , v arious inte r- 
fa ce standards, start-stop mode tetmind handling, multiplex 
intaiace for synchronous tcnmnaisrdeffiitibns of interface 
circuits and packet-network inteicoimection, all of which are 
hereby incorporated by reference. A thorough discussion of 
co mputernetwori: architect ure and protocols is included in 
a special issue of IEEE IVansactions on Communications, 
April 1980, Vol. COM-28, which also is incorporated hmin 
by reference. Most digital data communication is done by . 
character r^n^nted as sequences of bits with the numboc 
of bits per character and the sequence of 0*s and Ts that 
conespond to each character defining a code. The most 
common code is International Alphabet No. S which is ^ 
known in the U.S. as ASCH Other codes may also be used 
as the type of code used is not critical to the invention. 

In coded transmission, two methods of maintaining syn- 
chronism between the trasjst^^gjnln^vingpd^ 25 
conun only use d. In **start«stop'* transmissionTth e tntorval 
between characterslilepregented by a steady Hign al, and 
the transmissian of a single u tm signals the leceiving 
terminal that a character is starting. The data bits follow the 
start bit and are fidlowed by a stop pulse. The stop pulse is 3^ 
the same as the signal between characters and has a mini- 
mum length diat is part of the terminal specification. In the 
synchronous mediod, bits are sent at a uniform rate witii a 
synchronous idle pattern during intervals when no characters 
are being sent to maintain timing. The synchronous method 
is used for higher speed transmissioiL 

Protocols as that tmn is used in digital computer network 
communication are standard procedures for the operation of 
communication. Their purpose is to coordinate the equip- 
ment and processes at interfaces at the ends of the commu- 40 
nication channel. Protocols are considered to apply to sev- 
eral levels. The International Organization for 
Standardization (ISO) has developed a seven level Refer- 
ence Model of Open System Intc^onnection to guide the 
development of standard protocols. The seven levels of this 43 
standard hereafter refecred to as the ISO Model and their 
functions are: - 

(1) Application: Permits communication between appli- 
cations. Protocols here serve the needs of the end user. 

(2) Presentation: Presents structured data in proper form ^ 
for use by £q)plication programs. Provides a set of 
services which may be selected by the application layer 

to enable it to interpret the meaning of data exchanged. 

(3) Session: Sets up and takes dovsrn relationships between 
presentation entities and controls data exchange, i.e., 
dialog control. 

(4) Transport: Rirnishes network-independent transparent 
transfer of data. Rdieves the session layer from any 
concern witii die detailed way in wfaidi reliable and ^ 
cost-ejfective transfer of data is achieved. 

(5) Network: Provides network independent routing, 
switching services. 

(6) Data Link: Gives error-free transfer of data over a link 
by providing functional and procedural means to estab- 65 
lish, maintain anditelease data links between network 
entities. 
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(7) Physical: Provides mechanical, electrical, functional 
and procedural characteristics to establish, maintain, , 
and release physical connections, e.g., data circiuts 
between data link entities. 
Some data link protocols, historically the most common, 
use characters or combinations of characters to control the 
interchange of data. Others, including the ANSI Advanced 
Data Communication Control Procedure and its subsets use 
sequences of bits in predetermined locations in the message 
to provide the link control. 

Packet networks were developed to make more efficient 
use of network facilities than was common in the circuit- 
switched and message-switched data nietworks of die mid- 
60*8. In drcoit-switched networks, a channd was assigned 
full time for the duration of a call. In message-switched 
networks, a message or section of a serial message was 
transntitted to the next switch if a padi Qoop or trunk) was 
available. If noCthe message was stor^ 'uiiti]' a path was * 
available. The use of trunks between message switches was 
often very efficimt. In many circuit-switched applications 
though, data was transmitted only a fraction of the time the 
circuit was in use. In order to make more efficient use of 
Polities and for otiier reasons, packet networks came into 
existence. 

In a packet network, a message from one host or terminal 
to another is divided into packets of some definite length, 
usually 128 bytes. These packets are tiien sent from the 
origination point to the destination point individually. Each 
packet contains a header which provides the network with 
the necessary Information to handle the packet l^ically, 
the packet includes at least the network addresses of the 
source and destination and may include other fields of data 
such as the packet length, etc The packets transmitted by 
one terminal to another are interleaved on. the facilities 
between the padcets transmitted by other users to their 
destinations so that the idle time of one source can be used 
by another source. Various network contention resolution 
protocols exist to arbitrate for control of the network by two. 
or more destinations wishing to send packe^ on the same 
channel at the same time. Some protcicols utilize multiple 
physical chaxmds by time division or fixquency nniltiiriex- 
ing. 

The same physical interfece drcuit can be used simulta- 
neously witii more than one other temiinal or computer by 
die use of logical chamteiB. At any given time, each logical 
channel is used for conununication with some particular 
addressee; each packet hicludes in its header the identifica- 
tion of its logical channd, and die packets of die various 
logical channels are interleaved on the physical-interface 
circuit 

At the destination, the message is reassembled and for- 
matted before delivery to the addressee process. In general, 
a networic has an uitemal protocol to control the movement 
of data within the network. 

The internal speed of the n^ork is generally higher than 
the speed of any terminal or node connected to the network. 

Three methods of handling messages are in common use. 
"Datagrams" are one-way messages sent from an originator 
to a destination. Datagram packets are delivered indepen- 
dentiy and not necessarily in die order sent. Delivery and 
nondelivery notifications may be provided. In **virtual calls**, 
packets are exchanged between two users of the network; at 
the destination, the packets are delivered to the addressee 
process in the same order in which they were originated. 
"Permanent virtual drcmts? also provide for exchange, of 
packets between two users on a netwcnk. Each assigns a 
logical channel, by arrangement witii die provider of die 
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network, for exchange of packet with the other. No setup or 
clearing of the channel is then necessary. 

Some packet networks support tenmnals that do not have 
the internal capability to format messages in packets by 
means cf a padcet assembler and disassembler included in 5 
the network. 

The earliest major packet netwoik in the U.S. was ARP- 
NET, set np to connect terminals and host computers at a 
number of universities and government research establish- 
ments. The objective was to permit computer users at one 10 
location to use data or programs located elsewhere, perheq)s 
in a computer of a difierent manufacturer. Access to the 
network is through an interface message processor (IMP) at 
each location, connected to the host CQmputer(s) there and 
the IMP at other locations. IMP' s are not directly coimected 15 
to each other IMP. Packets routed to destination IMF's not 
connected directly to the source IMP. are routed through 
intervening IMP's until they arrive at the destination pro- 
cess. At locations where there is no host, terminal interface 
processors are used to provide access for dumb terminals. 20 

Other packet networks have subsequently been set up 
woridwide, generally operating in the virtual call nuxle. 

In early packet networks, routing of each packet in a 
message is independent Each packet carries in its header the 
network address of the destination as well as a sequence 2S 
number to permit arranging of the padcets in the proper 
order at the destination. Networks designed more recently 
use a 'Virtual circuit" structure and protocol. Tlie virtual 
circuit is set up at the begirming of a data transmission and 
contains the routing information for all the packets of that 30 
data transmission. The packets after the first contain the 
designation of the virtual circuit in their headers. In some 
networks, the dioice of route is based on measurements 
received from all other nodes, of the delay to every other 
node on the netwock. In stiU other network structures, nodes 35 
on the network are coimected to some or all the other nodes 
by doubly redundant or triply redundant pathways. 

Some networks such as Dialog, lymshare and Thleoet use 
the public phone system for interconnection and make use of 
analog transmission chaimels and modems to modulate 40 
digital data onto the analog signal lines. 

Other network structures, generally WAN's, use micro- 
wave and/or satellites coupled with earth stations for long 
distance transmissions and local area networks or the piiblic 
phcHie system for local distribution. 45 

There is a wide variety of networic structures and proto- 
cols in use. Further, new designs for network and transport 
protocols, network imerface cards, network structures, host 
computers and terminals, server protocols and transport and 
network layer software are constandy appearing. This means 50 
that the one thing that is constant in network design and 
operation is that it is constantly changing. Further, the 
networic addresses where specific types of data may be 
obtained and the access protocols for obtaining this data are 
constantly changing. It is an object of the oonununication 55 
interface software of the invention to insulate the program- 
mer of application programs from the need to know all the 
networks and transport protocols, network addresses, access 
protocols and services through which data on a particular 
subject may be obtained. By encapsulating and modulariz- 60 
ing all diis changhig complexity in the interface software of 
the invention, the investment in plication programs may 
be protected by preventing network topology or protocol 
dependencies from being programmed into the applications. 
Thus, when something changes on the network, it is not 65 
necessary to reprogram or scrap all the plication pro- 



The objectives are achieved according to the teachings of 
the invention by networic conununicadons software having 
a Uuee-layer architecture, hereafter sometimes called the 
HB*"^ software. In FIG. 17, these three layers are identified 
as die information layer, the service layer and the distributed 
communication layer. Eadi application program is linked 
during the compiling and linking process to its own copy of 
the information layer and tl^ service layer. The compiling 
and linking process is what converts the source code of the 
application program to the machine readable object code. 
Tluis, for example, ^Hcation program.!, shown at 340, is 
du^Uy linked to its own copy of layers of the software of 
the invention, i.e., the information layer 342 and the service 
layer 344. Likewise application 2, shown at 346 is linked to 
its own copies of the information layer 348 and the service 
layer 350. These two applications share the third layer of the 
software of. the invention called the distributed conmiuni- 
cation lay^ 352. Typically there is only one distributed 
communicadon layer per node (where a node is any com- 
puter, terminal or server coupled to the network) which runs 
concurrently with the applications in multitasking machines 
but which could be interrupt drivers in norunuldtasking 
environments. 

The second host 314 in Geneva in the hypothedcal 
network of FIG. 17 is rurming application program 3, 354. 
Hiis i^lication is linked to its copies of the information 
layer 356 and the service layer 358. A concurrendy nmning 
distributed commomcation layer 360 in host 2 is used by 
cqjplication 354. 

Each of the servers 310, 312and316 have a data producer 
versions of dte 3 l^er TIB^ software. There is a data 
consumer version of the TIB™ software which implements 
the "subscribe* function and a data producer version which 
inq)lements the ''publish" functioa Where a process (a 
program in execution under die UNK"^ definition) is both 
a data consumer and a data publisher, it will have libraries 
of programs and interfiBoe specifications for its TB™ soft- 
ware which incitement bodi the subscribe and pubUsh 
fimctions. 

Each of the hosts 300 and 314 is under the control of an 
operating system, 370 and 372, respectively, which may be 
different. Host 1 and host 2 may also be computers of 
different manufacturers as may servers 310, 312 and 316. 
Host 1 has on-board shared memory 374 by which appKca- 
tions 340 and 346 may corrununicate such as by use of a 
UNIX™ pipe or other interprocess conmiunication mecha- 
nism. Host 2 utilizes memory 378. 

In a broad statement of the teachings of the invention, the 
information layer, such as 342, encapsulates the TIBINFO'™ 
interface functionality, and the subject-based addressing 
functionality of the TTB™ software communication library 
30A of FIGS. IS and 16. The TIBINFO interface is defined 
in Section 4 of the software specification below. TIBINFO 
defines a programmatic interface by which applications 
linked to this information layer may invoke the protocols 
and services of the Subject-Addressed Subscription Service 
(SASS) conxponent 

FIG. 18 clsiifies the relationships between the process 
architecture of FIG. 15, the software arohitecture of FIG. 16 
and the 3 layers for the TIB™ software shown in FIG. 17. 
In FIG. 15, the communications library 30Ai8 a library of 
programs which are linked to die application 16 which 
provide nmltipte functions which may be called upon by the 
RMDP and TIBINFO interfaces. Subject-Addressed Sub- 
scription Services are provided by subject mapper programs 
and service discipline programs in die component labeled 
30A/30B. This con^ionent 30Ay30B also mchides library 
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programs that provide the common infirastructuie program 
code which supports, i.e., communicates with and provides 
data to, the protocol en^e programs of the TIB commu- 
nication daemon SOB. 

ThR TIBINFO interface is devoted to providing a pro- 5 
grammatic interface by which linked client applications may 
start and use subject-addressed subscriptions for data pro- 
vided by data producers on the netwoik wherever they may 
be. 

The RMDP interface provide the programmatic interface lo 
by which subscriptions may be entered and data received 
&om services on the netwofk by linked client applications 
which abieady know the names of fhe services which supply 
this data. Hie oommunicatiQn libraiy 30A in FIG. 15 sup- 
pUe$Ebiaiypn>grams which niay be called by linked client is 
q)plicatian8 to implement the Maxket-Data-Subsoiption 
Service (MDSS). This function creates subscription data 
feqiiested by service names l>y setting up, with the aid oif the 
da^non's appropriate protocol engine, a reliable communi- 
cation chaimel to one or more serveis which supply the 20 
requested data. Failures of individual servers are transparent 
to the client since the MDSS automatically switches to a new 
server which supplies the same services using the £q)propri- 
ate protocol engine. The MDSS also automatically balances 
the load on servers and implements entitlement functions to 2S 
control who gets access to a service. The reliable commu- 
nication protocols of the DCC library 30A/3dB such as 
intelligent multicast and reliable broadcast and the protocol 
engines of the daemon 30B are invoked by the MDSS library 
programs. More details are given in Section 3 of the TIB™ 30 
Specification given below. 

Referring to FIG. 19, which is oon^scd of FIGS. 19A 
and 19B, there is shown a flow chart for the process earned 
out, inter alia, at each of the 3 layers on the subscriber 
process side for entering a subscription on a particular 35 
subject and receiving data on the subject. Step 490 repre- 
sents the process of receiving a request fiom a user for data 
on a particular subject This request could come from 
another process, another macbiuft or ficom the operating 
system in soxxie embodimeiits. For puxposes of this exanqjle 40 
assume that die request comes to qiplication 1 in FIG. 17 
firom auset 

Application 1 (on the iQ>plication layer or layer 1 of the 
ISO Model) then sends a **subscribe request" to information 
layer 342 in FIG. 17. This process is represented by step 402 45 
in FIG. 19A. This subscribe request is entered by calling the 
^propriate library program in the linked library of programs 
which indudes the TIB-INFO inleif ace. This subroutine call 
passes the subjea on wMdi data is requested and a pointer 
to the callback routine in the requesting process that the so 
TIB-INFO library program on the information layer is to call 
when messages are received on this subject. 

The information layer 342 encapsulates a subject-to- 
service discipline tDZpping function whidi provides archi- 
tectural decoupling of the requesting process as that term is 55 
defined in the glossary heron. Referring to steps 404 and 
406 in FIG. 19A and to FIG. 17, the input to the information 
layer is the subject and the output is a caU to a service 
discipline on the service layer 344 in FIG. 17. The infor- 
mation layer includes the TIB-INFO interface and all library 60 
programs of the linked communications library 30A in FIG. 
15 involved with subject-to-service mapping. The informa- 
tion layer maps the subject to the service or services which 
provide data on this subjea as symibolized by step 404 and 
then maps this service or services to one or more service 65 
discqilines that, encapsulate communication protocols to 
co mmumrate with these services. This information layer 



then coordinates with the service discipline to assign a 'TIB 
channel" as symbolized by step 410. 

A *T1B channer* is like an "attention: Frank Jones" line 
on the address of a letter: This TIB channel data is usiBd to 
route the message to the process which requested data on 
whatever subject is assigned to that TIB channel. Each 
subject is assigned a TIB channel when a subscription is 
entered. There is a subscription list that correlates die 
subscribing processes, dieir network-addresses, the subjects 
subscribed to and the TIB channel numbers assigned to these 
subjects. Data on this list is used by tiie daemon to route 
messages rccdved at its port address to the proper request* 
ing process. Tins list is also used on the data publislier side, 
to cause messages on particular subjects to be routed to the 
port address of the machine on which the requesting process 
is running. Tlie communication layer of the TIB software 
associated witt the service writes the channel number data 
in the headera^of packets firom messages on particular 
subjects before these packets are transmitted on the network. 
At the receiver side, the TIB chaimel data in the header 
causes proper routing of the packet to the requesting process. 
The TIB channel abstraction and the routing function it 
implies is performed by the DCC library portion 30A/30B in 
FIG. 18 which is linked to each requesting process. 

Assuming there are two such services, these services are 
then mq)ped by the s^ce. disciplines on the service layer 
to the servers that provide these services as symbolized by 
step 411 

In one embodiment, the informatiQn layer selects and 
calls only one of the service discipline subroutines in the 
service layer as symbolized by step 406. The service disd-. 
pline then runs and assigns aTIB channel to the subscription 
subject as symbolized 1^ step 410. The caU £com the 
information layer also passes the pointer to a callback 
routine in the information layer to be called when messages 
on the subject arrive. 

In alternative embodiments, the information l^er may 
caU all the service disciplines identified in the subject-to- 
service discipline mapping process so as to set up commu- 
nicatian links with aU the services. 

In some embodiments, the names of altemative services 
and altemative servers are passed to the selected seryioe 
discipline or directly to the distributed communication layer 
by the infomuoion layer for use in setting up alternate 
communication links. This allows the distributed commu- 
nication layer to set up an alternate communication link to 
anothn* server in case of failure of the selected serv^ or for 
simultaneous communicatian link setup to increase the 
throughput of the network. In still other embodiments, the 
requesting process can call the service layer directly and 
invoke the appropriate service discipline by doing the sub- 
ject-tt>-service discipline m^>ping in the application itself. 
The data regarding alternate services and s»v^ can be 
passed by caUing a library subroutine in the DCC library of 
block 30Ay30B in FIG. 18 which runs and stoics the data 
regarding the alternates. 

In alternative embodiments, the information layer may 
assign the TIB chaimel to each subject or the service layer 
may assign the TIB channel acting alone without coordinat- 
ing with the information layer. Step 410 represents the 
embodiments where the service discipline assigns the TIB 
channel number by coordinating with the information layer. 
Messages sent by data provider processes will have the 
assigned subjea channel data included as part of their 
header infonnation. 

TIB channels are used by the communication layer (DCQ 
for filtering and routing purposes. Tliat is, the daemon 30B. 
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in FIG. 15 and piotocd engines BOB in HO. 18 know when pline which contains code which can be shared by all 
a message arrives at the daemon's poit address having subclasses of this service discipline to do common functions 
particular TIB channel data in the header that there arc suchassubscribeorcancel which axe done the same way on 
outstanding subscriptions for <kta on this subject The all servers that provide this service. The generic service 
daemon process knows the channels for whidi there are s discipline will then map the subscription request to one or 
outstandkig subscriptions because this information is srat to more of the different servers that provide the service. The 
the communication IfQrer by the service layec The daemon sovice discipline(s) code which encapsulates the cammu- 
30B stores data received from the service discipline regard- nication procedure peculiar to the selected server(s) is then 
ing all TIB channels having open subscriptions. The daemon called and runs to finish the process of setting up the 
then sends any message on a subject having an open lo subscription data stream with the selected server(s). 
subscription to processes at that port address which have The output of the service layer is a request to the corn- 
subscribed to messages on that subject The daemon does munication layer to the effect, "set up a communication link 
not know what the subject is but it does know there is a by whatever means you deem most appropriate with the 
match between TIB channels having (^n subscriptions and following server and services on the following subject 
subjects of some of the incoming messages. is channel." The service layer also sends a pointer to the 
Each node coupled to the computer network of FIG. 17 s^ce layer callback routine which will handle messages or 
such as host 300 has one network interface card and one port packets on.the requested subject This process is symbolized 
address. Hiis port address may be assigned a 'logical by stq) 416. In some embodiments the network addresses of 
channel" in some networks for inultiplexing of the network aU servers that run service processes supplying data on the 
card by multiple processes running simultaneously on the 20 requested subject are passed to a DOC library program 
same host These port addresses may sometimes hereafter wMch stores diem for use in providing a reliable commu- 
also be referred to as network addresses. How data gets bade nication link by providing faDure recovery in case the 
and forth between network addresses is the responsibility of selected server crashes. 

the communication layers such as layer 352 in FIG. 17 Step 418 rqirescnts the process v/hm the selected pro- 
which invokes the transport layer, network layer, data link 25 tocol engine sets up the requested data link by invokiAg 
layer and physical layer functionalities of the operating selected functions of the transport layer protocols encq)su- 
systems 370 and 372, network interfsice cards (not shown) lated in the operating systent These protocols invoke other 
and other circuits on the network itself such as might be oonummication protocols on the network, linV and 
found in gateway 306 and WAN 308. physical layers so as to set up the requested data link and log 
The service layer, information layer and communication 30 onto the service as symbolized by step 420. Tlie service layer 
layer are layen which are "ontop^* of die ISO model layers, service disdpline usually then sends a message to the 
i.e., they pofonn services not performed on any layer of the service notifying it of the subscription and the TTB channel 
ISO model or they perform *Vahie addeif' services as an assigned to this TIB as synibolized by step 422. The subject 
adjunct to services performed on an ISO model layer. rfmnngi 1$ noted by the information service and/or commu- 
The purpose of the service layer is, among other things, to 3S nication l^er of the TTB interface software Unked to the 
provide service decoupling as that term is defined in the service. This allows the TIB channel data to be added to the 
glossary hereut Service decoupling frees the application of packet headers of transmitted packets on the subject of 
the need to know the details of how to communicate which interest This subscription message starts the flow of data in 
services. Tb perform this function, the service layer includes some embodiments, while in other embodiments, the flow of 
a program or function to m^ the selected service to all 40 data starts when the data link to the server is first established 
servers that provide this service and pick one (step 412 in In some embodiments, a single subscription may neces- 
FIG. 19). The service layer then maps the selected server to sitate calling multiple services, so the information layer may 
a protocol engine tiiat encapsulates the communication map the subject to multiple service disciplines. These in tum 
procedures or protocols necessary to traverse the network, map the request to multiple protocol engines which simul- 
i.e., set up a data link regardless of the path that needs to be 45 taneously set up data links to the multiple services, 
followed through the network to get to this server, and In some alternative embodiments, the s»vice disciplines 
communicate with the selected server regardless of what talk directiy to the transport layer and encapsulate the 
type of machine it is, what type of network and network card protocols necessary to communicate on the current netwoik 
it is coupled to and what operating system this server runs. configuration. In these embodiments, the service layer may 
This process is symbolized by step 414, 50 filter iiu»ming messages by subject before callhig the call- 
in alternative embodiments, the application or subscribing back routine in the information layer, 
process may call the protocol engine directiy by having done On small networks, an alternate embodiment is to broad- 
its own subject based addressing and encapsulating its own cast subscription requests to particular subjects on tiie net- 
communication proU)Col. In other alternative embodiments. work. Services coupled to the network listen to these broad- 
die service layer will select all the servers suj^ying a 55 casts and send messages on the subjects of interest to the 
service and request the commumcation layer to s^ up data port addresses identified in the broadcasts. Tliese messages 
links with all of them simultaneously to increase die are then directed by the DGC layer at the port address to the 
throughput of the network or to use one server and switch to requesting process in the manner described elsewhere 
another upon failure of the selected server. herein. 

Normally all services diat provide a selected service are 60 In alternative embodiments, the service layer also per- 

assumed to use the same commimication protocol so a single forms other functions such as: regulating access to certain 

service discipline can conmfiunicate with them aU. However, services; session management in the traditional sense of the 

if different instances of the same services or diffisrent ser- session layer of die ISO model; replication management of 

vices providing data on the same subjects use different replicated services and servers; failure/recovery manage- 

communication protocols, the teachings of the invention 65 ment in case of failure of a service; distribution manage- 

contemplate subclasses of service disciplines. This means ment; load balancing to prevent one server or service from 

that the information layer will call a generic service disd- being inequitably loaded with data requests when other 
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services/servers can fill the need; or, security functions such 
as providing secure, encoded communications with a server. 
Of particular importance among these alternate embodi- 
ments are the embodiments which encapailate service 
recovery schemes on the service layer. In these embodi- 5 
ments, when a server goes down, a recovery scheme to 
obtain the same data elsewhere encapsulated in the appso}- 
priate service discipline is run to re-establish a new data link 
to an alternate server as symbolized by step 424. 

In die prefened embodiment, die semce discipline lo 
assigns the TIB channel to the subject and indcs thepiotoool 
engine to use in tenns of the characteristics of the seiver and 
the service to be accessed and the netwodc and network 
protocol to be used, and in light of the degree of reliabifity 
necessary. 15 

The daemon 30B in FIGS. 15 and 18 can include many 
different protocol engines, each of which has different 
chi^teristics. For example there may be a protocol engine 
for point-to-point communication between nodes having 
Novell network interface cards and using the Novell proto- 20 
col and a protocol oigine for point-to-point communications 
between nodes using the TCP and UDP protocols and 
associated netwc^ interface cards. There may also be a 
protocol engine for communication with high speed data 
publishers using reliable broadcast, and a protocol engine is 
for either point-to-point or reliable broadcast communica- 
tion using the Intelligent Multicast™ protocol. There can be 
as many protocol engines as there are options for commu- 
nication protocols, types of servers and services and reli- 
ability options, and more can be added at any time. 30 

Further, some of the service disciplines may be proce- 
dures for communicating with otho* processes on the same 
machine such as the operating system or another plication 
or direcUy with a user through a terminal. More service 
disciplines can be added at any time to communicate widi 35 
new sources of information. 

A service discipline, when it receives a subsoipdon 
request may open a sptdtc TIB chaimel for that subject or 
allow any arbitrary TIB channel to be used. 

The selected service discipline or disciplines pick the 40 
protocol engine that has die right charactetisdcs to e£S- 
denUy conununicate with the selected service by calling a 
DCC library program. The DCC library program updates the 
subscription list widi the new subscription and channel data 
and sends a message to the selected protocol engine via 4S 
shared memory or some other mterprocess transfer mecha- 
nisia If the host is not muldtasking, die daemon will be 
caused to run by an interrupt generated by the DCC lilnary 
program The message to die selected protocol engine will 
be as previously described and will include the identity of 50 
the selected server. The protocol engine will map the identity 
of this server to the network address of the server and carry 
out the communication protocol encsq)sulated within the 
selected protocol engine to set up the data link. Some of 
diese protocols are value added protocols to, for example, 55 
increase the reliability of generic transport layer broadcast 
protocols or to do intelligent multicasting. These value 
added protocols will be detailed below. This step is sym- 
bolized by step 426. 

The distributed commumcatioQ layers 352 and 360, func- 60 
tion to provide configuration decoupling. This eliminates die 
need for the requesting process to know how to do various 
oommunication protocols such as TCP, UDP, broadcast etc 
and to have code therein which can inq)lement these proto- 
cols. The protocol engines inq)lement various communica- 65 
tion protocols and the DCC lilnary implements the notion of 
TIB diamiels and performs routing and filtering by subject 
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matter based upon the HB channel data in the packet 
headers of incoming packets. The protocol engine fm* coni- 
municating using the UDP protocol also does message 
disassembly into packets on the service or transmit side and 
packet reassembly into complete messages on the subscrib- 
ing process or receive side. This is a value added service 
smoe die UDP transport protocol does not include these 
disassembly and reassembly, functions. Hie TCP transport 
protocol indudes these message disassembly and padcet 
reassembly functions so the protocol engme that invokes this 
transport layer function need not supply these type value 
.added services. 

In some embodiments of the invention, the UDP protocol 
engine adds sequence numbers and data regarding how 
many packets comprise each complete message to the packet 
headers. This allows die daemon or DCC library of die 
receiving process TIB conimunication layer to check the 
integrity of the message received to insure that all packets 
have been received. 

As data packets come in ton the network, they are 
passed up through the DCC library, service layer and infor- 
mation layer to the subscribing process. The service layer in 
some embodiments may filter the incoming messages by 
subject mattCT instead of having this filtering done by the 
daemon or the DCC hbrary as m other embodiments. In still 
other embodiments, the filtering by subject matter is done by. 
the information layet 

In some embodiments, the service layer also performs 
data formatting by calling programs in die TIB FORMS 
interface 231 in FIG. 15 or die TIB Fbims Library 32 in FIG. 
1. 

In some embodiments, the subject based addressing is 
done by collecting aU die information a subscxibmg process 
could ever want in a gigantic data base and oiganizing the 
data base by subject matter widi updates as data changes. 
The service layer would then conqnise routines to map die 
subject request to data base access protocols to extract data 
finm die proper areas of die data base. The communication 
layer in such embodiments m^ incommg update data to 
update protocols to update die i^iproptiate date in die data 
teLse. 

The preferred embodiment implements die more powerful 
notion of allowing the data sources to be distributed. This 
allows new servers and services to be coupled to the system 
widiout causing havoc or obsolescence widi all the esdsting 
supplication software. The use of the information, savicc and 
communication layers of the TIB software according to the 
teachings of die invention provides a v«y flexible way of 
decoupling the application software from die tvcr changing 
netwcnk below it 

In the prefened embodiment, die filtering by subject 
matter for point-to-point protocols is done by the TIB 
software on die transmit side. Note that in FIG. 17, the 
servers 310, 312 and 316 are decoupled from die network by 
TIB interface software symbolized by the blocks marked 
'TIB IF\ l^rminal 320 is also decoupled in die same 
manner and can be a service for manual entry of data by the 
user. Specifically, this filtering is done by the information 
layer bound to the service which is publishing the data. For 
a service that is using die broadcast transport protocol, the 
TIB communication layer at die network addresses receiving 
the broadcast would filter out all messages except those 
having subjects matching open siibscriptions by conq)aring 
the TIB channel data to the channel data for open subscrip- 
tions listed in the subscription table based upon subscription 
data generated by die information layer and TIB channel 
data generated by die service layer: Note diat where a service 
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simply broadcasts data, the service discipline for acoessiiig 
that service can be as simple as "listen far daia aniving at the 
following network address and filter out the messages on 
other thm the subscribed subject" Hie service discipline 
would then format tiiie data properly by invoking the proper 5 
function in the TIB Forms Library and pass the data through 
the information layer to the requesting process. 

The use of the communication layer allows all the net- 
work configuration parameters to be outside the plications 
and subject to revision by the system adnunistrator or 
otherwise when the network configuration changes. This 
insulates the application software from the network interfece 
and provides a functionality similar to and incorporating at 
least all the functionality of the ISO Model netwo^ layer. 

Note also that in some embodiments, the functionality of 
the information, service and communication layers could 
also be easily implemented in hardware ratto than the 
software of the jHcferred embodiment The service and 
communication layers implement most of the functionality 
the ISO Model Netwoik, Data Link and Phydcal laym phis 
more. 20 

In some embodiments, the distributed communicatian 
layer only receives a general request from the service layer 
to set up a data link and decides on its own which is the most 
efiScicnt protocol to use. For example, the DCC may reoeive 
S separate subscriptions for the same informatioa The DCC 25 
may elect on its own to set up 5 separate data links or bundle 
the requests, set up one data link and distribute die airiviog 
message by interprocess transfers to each of the 5 lequestii^ 
processes. In other embodiments, the DCC may act on its 
own to decide which protocol tousie, but may accept Ibiiigs 30 
finom the service layer such as, '1 want this fast" or *1 want 
this reliaMe*'. In the latter case, the conmuimcatloD layer 
may elect to send two subscriptions for the same iofbimatiQn 
to two diffeiem services or may set up two diffierent links to 
the same service by different network paths. 35 

In the prefieired embodiment, the DCC library portion of 
die communication Hbraiy serves the sole function of deter- 
mining how to best get data from one network address to 
another. All replication management and failure recovery 
protocols are encapsulated in the service discipUnes. 40 

Referring to HG. 20, comprised of HGS. 20A and 20B, 
there is shown a flow chart for the processing involved at the 
three layers of the TIB software on the transmit side in 
creating a subscription data stream at a publishing process or 
service and sending It down through the TIB software and 45 
across the network to the subscribing process. 

Step 430 represents the process whereby the selected 
service receives a message from a subscribing process and 
initiates a data stream. Each service such as the Quotron 
service running on server 310 in FIG. 17 and the Maiketfeed 50 
2000 and Teleratc services running on servers 312 and 316, 
respectively, are decoupled from the netwoik by a version of 
the three layer architecture TIB software according to the 
teachings of the invention. This is symbolized by the blodcs 
marked TIB IF in these server boxes which stands for TIB 55 
interface software. 

The TIB interface for each service decouples the service 
from any requirement to have functionality capable of 
supporting filtering or subject based addressing. Thus, if a 
service is designed to broadcast all equi^ prices on the 60 
American Stock Exchange and Over-the-Counter maricet, 
bat the subscription is simply for IBM equity prices, the 
service responds as it always has and need not have a 
function to filter out only IBM equity prices. The service 
discipline for this type service will be adapted to filter out all 65 
messages except IBM equity prices in response to such a 
subscription request 
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Another service like Telerate which publishes many dif- 
ferent pages organized by subject matter, e.g., a page on 
Government T-Bill rates, a page on long temn corporate bond 
rates etc., will be able to accept a subscription for only a 
specific page and may be able to accept special commands 
to cause the service to publish only specific columns on a 
particular page. In such a case, the service layer bound to 
such a service will include a service discipline which 
receives subscription requests by subject and filters mes- 
sages from a broadcast that do not pertain to a subject having 
an open subscriptipa 

Step 430 also represents the process of the service calling 
the T©-Publish function of the information layer TIB-INFO 
library and starting the flow of data toward the subscribing 
process. The service need not have any of its own ability to 
filter by subject The subscription request it receives is in the 
''native tongue" that this service understands because it is 
formatted and sequenced in that fashion by the service 
discipline of the subscribing process. 

Most of the filtering by subjea matter is done by the 
service disciplines, but where this filtering is done depends 
upon the type of service. Some services publish only one 
type of data so everything such a publisher puts out is of 
interest to the subscribing process. For example, assume that 
the service accessed is the real time clock 371 in HG. 17 
which puts out only the current time, and assume that the 
subject of the subscription is ''give me the time of day". In 
such a case, the service discqpHne is very simple and no 
filtering need occur. Such a service discq)line can be simply 
a protocol to determine how to communicate the data to the 
requesting process and what TEB channel to assign to it 

The fiict that the service starts sending data in whatever 
manner such a service normally sends data is symbolized by 
step 432. Thus, if the service is TUetate, it can send the page 
image and updates for any one of a number of difEjerent 
pages and it understands a subscription for only one of its 
many pages whereas the Quotron service would not imder- 
stand a subscription for only IBM equity prices. The various 
service disciplines of the service layer provide, inter alia, the 
necessary fimctionality which the service does not have. 

Step 432 assumes a service which broadcasts messages on 
many different subjects and a subscription request for only 
one or a few of those subjects. In other hypothcticid 
examples, the service may publish only the requested infor- 
mation such as a particular telerate page. In the Telerate 
case, the subscription request may specify that only a 
particular page and particular columns of that page be sent 
and may request the page image by a point-to-point com- 
munication protocol using a dedicated TIB channel. 

Step 434 represents the response processing of the service 
layer to the subscription request and the stream of data that 
rKults. In step 434, the service discipline does any necessary 
filtering by subject matter and assigns the TIB channel 
number. The filtering by subject matter is generally done by 
the service discipline on the data producer side of an 
exchange only when the producer prodices vastly move data 
than is called for by the subscription such as in the case of 
a high speed, broadcast producer. In such a case, the 
extraneous data could ov^hehn the networic. The TIB 
channel numbers are assigned by the service discipline in 
step 434 but they are not actually added to the headers for 
the packets until the message reaches the conununicati(» 
layer. In some alternative embodiments, the TEB channel 
numbers may be written to the packet headers by the service 

riforiplinp. 

The TEB charmel number assignment is done by the 
service disdpline based upon die ^pe of service, subscrip- 
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tion and communication protocol being nsed. Wheie a subscribing processes. If the transport protocol in use is 

broadcast protocol is being used« the service disdpline in UDP, the protocol engine, in some embodim^ts, will do a 

some embodiments will, in step 434, sinq)ly assign diffident packetizing function. Tlus is the process of breaking down 

TIB channel niunbera to different subjects and send a the message into packets and adding header data on the 

messi^e to subsciiben listed in a subscription table main- 5 transmit side and reassembling the packets in the proper 

tained by the service layer on the information layer. The order on die receiver side. The TCP transport protocol does 

message will say simply, for example, *Tor updates on IBM its own packetizing, so protocol engines that invoke this 

equity prices, monitor TIB channel 1W\ Note that the TIB transport layer need not packetize. Nonpacket protocol 

cbannd data is used by the TIB software of the receiving engines also exist for other types of transport protocols, 

host solely to route messages to die proper subscrifaix^. The protocol engine also writes the port address of the 

processes. TIB channels have nothing to do with logical machine running the subscribing process in the message 

channels, network routing or other netwock, data Hnk or heaiders and may p ci foi m other value added services. These 

physical layer issues. other services inchide reliable broadcast and Intelligent 

In other end)odiments, in the broadcast protocol situation. Multicasting. Reliable broadcast services will be explaiiied 

the service discipline will consult a subscription list and below, but basically this service provides functionality that 

filter out all messages on subjects other than sutvjects with does not exist in cunent broadcast connmunication protocols 

open subsGiipticms. For those subjects, a TIB chmiiels will to increase reliability. 

be assigned and a message will be sent to the TIB software Tbe protocol engines have a standard programmers inter- 
linked to the subscribing proc^es as to what HB channels " face' througlT which they cmhmuhicate' with die' transport 

to listen to for messages to be routed to their client pro- layerroutincs in the operating system. The steps taken by the 

cesses. 20 protocol engine to invoke the transport layer ftmcdonality so 

In tbe case of point-to-point protocols, die subscription as to drive the network, data-link and phyacal ikyer proto- 
requests usually contain the TIB channel numbers assigned cols in such a manner so as to deliver die messages to die 
to the subject by the service disdpline selected by die subscribing processes are not cntical to the invention are 
infortnation layer linked to die subscribing process. In such symbolized by steps 440 and 442. ExacUy what these steps 
a case, step 43M represents tbe process of assigning the TIB 25 are cannot be specified here because they are highly depen- 
channel number received in die subscription request to dent upon the structure^ configuration and protocol of the 
messages emitted firom the service. In a typical case of a netwaric as well as the inter&ce to the transport layer. When 
subscription to a Iblerate page which specifies that a par- any of these diange, the protocol engines may have to be 
ticular TIB channel is to be used in case a point-to-point changed to accommodate the change to the network. This, 
protocol is selected, the service discipline will send the page 30 however, prevents the need to change the ^iplication soft- 
image by selecting a point4o-point protocol engine. The ware thereby providing configuration decoi^ding. 
service discipline will also send a message acknowledging After the message traverses die network, it is picked upby 
die subscription and advising die TIB software of die the network interface card having the port address shared by 
subscribing process to listen to a particular TIB channel for die subscribing process. This process is symbolized by step 
broadcasts of updates to die page. The receiving TIB soft- 35 444. The network card buffers die message and generates an . 
ware then opens a TIB broadcast channel for die updates. interrupt to the transport layer routine which handles incom- 

Step 436 represents die processes performed by die DCC ing messages, 

library after die service discipline calls it The DCC lilvary's Step 446 represents the process where die transport layer 

sole ftmction in the preferred embodiment is to determine software calls the ai^mspriate protocol engine of the daemon 

die tiest way to send a message to any particular network 40 SOB in the conununication layer such as layers 352 or 360 

address where the service disdpline or the subscription in FIG. 17. The incoming message or packet will be passed 

request does not specify the communication protocol to be to the appropriate protocol engine by some interprocess 

used. In some embodiments, the DOC library of the com- transfer mechanism such as shared memory. In the preferred 

munication layer will 2ccepi suggestions fipom the service embodiment, the daemon is an ongoiiig process running in 

layer or subscription request as to how to send the message 45 background on a multitasking macfauie. In other embodl- 

but may select a different protocol if diis is deemed to be ments, die daemon is interropt driven and only runs when a 

more efficient message has been received or is to be ttansmitted. Step 446 

Rirther, die DCC lllaary may change the communication also represents the packet reassembly process for TCP or 

protocol being used based upon changing conditions such as other transport layer protocols where packet reassembly is 

number of subscribers. For example, an Intdligrait Multicast 50 done by the transport layer. 

protocol may be chosen (described in more detail below). In Step 448 represents the processes perftinned by the {ho- 

this protocol, a point-to-point protocol is used when the tocol engine in the daemon to process and route the incom- 

number of subsoibers is below a certain cutoff number ing message. 

(programmable by die system administrator) but switchover For UDP transport layer protocol engines, packet reas- 

to a broadcast protocol automatically occurs when the 55 sembly is done. This of course implies diat the protocol 

number of subscribers rises above the cutoff number. In the engine of the data producer process added sequence num- 

preferred embodiment *Tiigh- water" and "low- water" marics bers to die packtt headers so that diey can be reassembled 

are used as will be described below. In other embodiments, in the progei order. Other value added services may then be 

any cost function may be used to set the switchover point performed such as checking all the sequence numbers 

based upon cost and efficiency of sending multiple point- 60 against data which indicates the sequence numbers which 

to-point messages as opposed to a single broadcast message. should have arrived to determine if all the packets have been 

Step 436 also represents the process of retrieving the received. In some embodiments, the data as to the sequence 

message from local memory of the service and putting it into numbers to expect is written into fields dedicated to this 

an interprocess transfer process to send it to die protocol purpose in the packet headers. In other embodiments, dus 

engine/daemon 30B in FIG. 15. 65 data is sent in a separate message. 

Step 438 represents die processes carried out by the If any packets are missing a message will be sent auto- 
protocol engine of the service to transmit the messages to the matically by the receiving communication layer back.to the 
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co mnn i Tri c ati oii layer of the data producer process to request 
retransmissiQn of any lost or garbled packets. This of course 
impUes that the communication layer for the data process 
stores all packets in memory and retains them for possible 
retransmission until an acknowledgment message is 5 
received indicatii^ that all packets have been successfuUy 
received. 

Step 448 also symbolizes the main function petformed by 
the communication layer daemon/protocol engine in receiv- 
ing xiiessages. That function is routing the messages to the 10 
appropriate subscribing process according to the TIB chan- 
nel information m the header. The protocol engine checks 
die TIB channel number in the header against the current 
subscripdon list sent to it by the service discipline. The 
subscription list will include pointers to the ^^priate 15 
service discipline callback routine and subscribing |xocess 
for messages assigned to any particular . TIB channel. The 
protocol engine also filters messages by HB channel num> 
ber for embodiments in which messages reach the TIB 
software coupled to the subscribing process which do not 20 
pertain to the subject of an open subscription. This may also 
be done at the service layer, or information layer but it is 
most efficient to do it at the communication layo*. 

The protocol engine will dien put the message in the 
appropriate interprocess transfer mechamsm, usually shared 2S 
memory or a Unix™ pipe, and generate an interrupt to the 
DCC library as symbolized by step 450. This interrupt will 
vector processing to the appropriate DCC Mbmy callback 
routine which was id^fied to the protocol engine by the 
DCC library when the subscription on this TIB channel and 30 
subject was opened. The DCC lifataiy icmtine so invoked is 
linked to and part of the subscribing process whi^ initiated 
the subscription. Tlie DCC libraiy callback routine then 
retrieves the message from the interprocess transfer mecha- 
nism and stores it in local memory of the subscribing 3S 
process. Hie DCC library callback routine then generates an 
intOTupt to the service layer and passes it a pointer to tiie 
message. 

Step 452 represents die pmcess performed by the service 
layer on incoming messages. The interrupt from the E>CC 40 
library causes to run the service discipline callback routine 
identified in the original subscribe message passed by the 
service layer through the DCC library. The callback routine 
will, in some embodiments, do any data format conversions 
necessary and may, in other embodiments do subjea matter 45 
filtering. TTien, the service discipline generates an intemipt 
to ±e information layer which cause die callbadc routine of 
the informalion layer to run. The intcnupt contains a pointer 
to the message. 

Step 454 symbolizes processing of incoming messages by 30 
the information layer. In some embodiments, the service 
layer does not guarantee that all messages reaching the 
information layer exacUy match the subject for which data 
was requested In these embodiments, step 454 symbolizes 
the process of comparing the TIB channel code to the subject S5 
of the subscripti(»i to make sure they match. If the data has 
been previously filtered by subject, stq) 454 can be elimi- 
nated. 

Step 456 symbolizes the process of generating an hiter- 
nipt to die callback routine of the subscribing process if 60 
dim is a match on subject If not, no interrupt is generated 
and monitoring for new messages continues by the daemon 
while all die interrupt driven {Hocesses termumte and release 
their computer resources until the next interrupt 

Step 458 symbolizes the process of use of the message 65 
data for whatever purpose the subscribing process originally 
sought this data. 
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Reliable broadcast is one of die value added services that 
die communication layer can use to supplement and improve 
die communication protocols of the transport layer. Tradi- 
tional broadcast protocols offered by prior art transport 
layers are not reliable. For example, if these is noise on the 
line which conupts or destroys apacketor message or if the 
network interface card overflows the buffer, packets or entire 
messages can be lost and the processes listem'ng for the 
message never gets die message, or diey get an incomplete 
or garbled message. Tliere is no acknowledge function in 
traditional broadcast, so if some of the processes miss the 
message or get incomplete or garbled messages, the trans- 
mitting process never finds out Hus can h^»pen for one in 
every hundred packets or for one in ten packet Traditional 
prior art transport layer broadcast protocols do not include 
functionality, i.e., program code, to distribute a broadcast 
message received at. the network address .of the host to. 
multiple processes running on that host 

The conununication layer according to the teachings of 
the invention includes at least one protocol erigine to imple- 
ment reliable broadcast protocols which are built on top and 
supplement the functioriality of the prior art transport layer 
broadcast protocols. Referring to FIG. 21 comprised of 
FIGS. 21A and 21B, there is shown a flow chart for one 
embodim^t of a reliable broadcast protocol implemented 
by die communication layer. Step 500 icfResents the ixrooess 
where the DCC libraiy receives a request firom a service 
discipline to said a message having a particularTIB chaimel 
assisted thereto. In some nnbodimcnts. dus request may 
also include a request or a command to send the message 1^ 
the reliable broadcast protocol. In embodiments where die 
reliable broadcast protocol is mandated by die service dis- 
cipUnie, die service discipline includes a function to deter- 
mine die number of subscribers to a particular channel and 
determine the cost of sending the same message many times 
to all die port addresses of all subscribers versus the cost of 
sending the message once by broadcast with messages to all 
subscribers to listen to TIB channel XX (whatever TIB 
channel number was assigned to this subject) for data on the 
subjects they are interested in. In the embodiment illustraled 
in FIG. 21, this cost determination function is included 
widiin die communication layer DOC library functionality. 

Step 502 represents this cost determination process as 
performed by the DCC library. The particular program qf die 
DCC tibrary which implements diis function, checks the 
subscription list and counts the number of subscribers to die 
TIB channel assigned to diis message. The cost of sending 
the message point-to-point to all tiiese subscribers is tiien 
evaluated using any desired costing function. In some 
embodiments, the cost function may be a comparison of the 
number of subscribers to a predetermined cutoff number. 
The particular cost function used is not critical to the 
invention. The cost of sending the message to multiple 
subscribers point-to-point is diat die same message must be 
placed repeatedly on die networic by the data producing 
software. The cost of broadcasting a message is that all 
network cards pick it up and may interrupt the transport 
protocol program in the operating system of die host which 
transmits the message by interprocess transfer to the HB 
daemon only to find out die messs^e is not of interest to any 
client process running on diat host Computer resources are 
thus wasted at aiiy such host 

Step 504 represents the process the DCC library carries 
out to evaluate the cost and decide to send die message eiUier 
by point-to-point protocol or reliable broadcast If it is 
determined that the number of subscribers to dus TIB 
channel is small enough, the decision will be made to send 
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ttie message by a point-to-point protocoL Step 506 repre- 
sents the process of calling the point-to-point protocol 
engine and sending the message using this protocol 

If the number of subscribers is too high for efficient 
point-to-point transmission, the DCC Hhrary calls the reli- 5 
able broadcast protocol oigine as symbolized by step 508. 

Step 510 represents the first step of the reliable broadcast 
protocol processing. The reliable broadcast protocol accord- 
ing to the teachings of .the invention supports multiple 
subsctibing processes lunmng of the same host and requires lO 
that each subscribing process receive aD the packets of the 
message without enor and acknowledge receipt tfaeieof. To 
insure that this is the case, sequence numbers must be added 
to the headers of each padcet and some data must be 
communicated to the subscribing processes that indicate the 15 
sequence nuihbeis that must all have been received in order 
to have received the entire message. In some embodiments, 
only die sequenob niun^ will be*added to the packet 
headers and the data regarding the sequence numbos that 
comprise the entire message wQl be salt by separate mes- 20 
sage to each process having an open subscription to the HB 
channel assigned to the message. In other embodiments^ the 
sequence numbers that conqnise the entire message will be 
added to die header of the fint packet or to the headers of all 
the packets. The sequence numbers added to the packets are 2S 
different than the sequence numbers added by packetizing 
functionality of the tran^ort protocols of the operating 
system in TCP protocols since the TIB sequence numbers 
are used only to determine if all pockets of a message have 
been receivoL In some embodiments, the packet sequence 30 
numbers added by the transport protocol may be used by the 
TIB communication layer of the subscribing processes to 
determine if all the packets have been received. In other 
embodiments of reliable broadcast protocol engines for 
supplementing the UDP transport layer protocol, the pack- 35 
etiziqg fimcdon of the protocol ei^gine adds sequence num- 
bers which can be osed both for transport/network/data 
link/physical layer functions but also for TIB 
tion layer functions in verifying that all padoets of a message 
have been received. 40 

After the sequence numbers have been added, the packets 
are written to a letnutsmit buffer with tlieu: sequence num- 
bers for storage in case some or all of the packets need to be 
retransmitted later as symbolized by step 512. 

Before the messages can be sent to the various subscrib- 4S 
ing processes, the reliable broadcast protocol engine adds 
the TIB channel data to the header of each packet and sends 
a message to each subscribing process listed in the subscrip- 
tion table as having open subscriptions for this channel to 
listen for data on their requested subject on TIB channel XX 50 
where XX is the TIB channel number assigned to this 
subject 

Step 516 represents the process of transmitting the pack- 
ets via the standard broadcast protocols of the transport layer 
by calling the ^ipropriate operating system program and 55 
passing a pointer to each packet 

Referring to FIG. 22 comprised of FIGS. 22A and 22B, 
there is shown a flow chart of the processing by the 
communication layer of the subscribing process in the 
reliable broadcast protocol. The packets broadcast on the 60 
netwOTk are picked up by all networic interface cards of all 
hosts on the networic which then invoke the transport 
protocol software of the operating systems of the various 
hosts. The transport protocols then nolify the daemons of the 
comxnunication layers that a broadcast message has arrived 65 
and puts the packets in an inteiprocess transfer mechanism, 
usually shared memory. The daemons dien retrieve the 
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packets from the interprocess transfer mechanism as repre- 
sented by step 518. 

Step 520 represents the process of checking the TIB . 
channel numbers of the incoming packets to determine if 
they correspond to the TIB channel of any open subscrip- 
tion. If they do, the reliability sequence numbers are checked ' 
by the reliable broadcast protocol engine against the data 
indicating which packets and corresponding sequence num- 
bers should have been received to have received a complete 
message. In some embodiments, especially embodiments 
using transport, netwoik, data link and physical layers where 
error checking (ECC) is not performed at layers bdow the 
TIB interface software of the inventian, enor detection and 
correction is performed on the packets using the ECC bits 
appended to the packet If errors have occurred that are 
beyond the range of oonection given the number of ECC bits 
present, the packet is marked as garbled ^ 

After determining 'which packets are missing or garbled^ " 
if any, the receiving protocol engine then sends a message 
back to the communication layer of the service or publishing 
process. This message wiU either acknowledge that all 
packets have been received without a problem or will 
request that certain packets be retransmitted. This is sym- 
bolized by step 522. 

Step 524 represents the process of retransmission of the 
missmg or garbled packets by the communication layer of 
the data producing process or service. In some embodi- 
ments, the missing or garbled packets will be sent point-to- 
point to only the subscribing process that did not get them. 
In other en^diments, the missing or garbled packets are 
broadcast to nodes with notification messages being sent to 
the subscribing processes that need them to listen on TIB 
channel XX where XX is the TIB channel on which the 
packets will be broadcast The phrase "listen to channel XX^ 
as it is used here has nothing to do with the actual , trans- 
mission firequency, timeslot or other physical characteristic 
of the transmission. It merely means that the trnRsing or 
garbled packets will be appearing on the networic shortly and 
will have TIB channel XX routing infonnation .in their 
header data. 

Step 526 represents the process of checking, by the 
receiving communication layer diat the replacement packets 
have been properly received simflar to Ae processing of step 
520. If they have, the receiving comimmicaticm li^er 
acknowledges tiiis fact to the conunumcation layer of the 
service. If not, a request foriettansmission of the misshig or 
garbled packets is again sent to the communication lay^ of 
the transmitting process, retransmission ensues and the 
whole process repeats until all packets have been success- 
fully received, llie final acknowledge message from the 
receiving communication layer to the transmitting commu- 
nication layer that all packets have been successfully 
received causes the reliable broadcast protocol engine of the 
transmitting communication layer to flush all the packets 
fipom the retransmission memory as symbolized by step 52S. 

Step 530 represents the routing process wh^ die rdiable 
broadcast protocol engine checks the TIB diannel data 
against the subscription list to determine which client pro- 
cesses have requested data assigned to this TIB charmel. 
Once this information is known, the protocol engiiie passes 
a pointer to the message to all service disciplines which have 
entered subscriptions for data on tiiis TEB channel In sonae 
embodiments, the protocol engine will place a copy of the 
message in a separate interprocess transfer mechaniRm for 
every subscribing process. In other embodiments, shared 
memory will be the int erpr ocess transfer Tni»nhflnigTn and a 
pointer to the same copy of the message be sent to all 
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subscribing processes. The subscribing processes will then 
arbitrate for access to the message in the infonnation layer 
or the service layer. 

Step 532 represents the processes previously described of 
passing the message up through the service and infonnation 5 
layers to the subscribing process by successive interrupts 
causing to run the callback routines riRsignntftd when the 
subscription was entered Hltering by subject matter may 
also occur in some embodimoits at the service layer and/or 
the information layer to guarantee a match to the subscribed . 
subject. 

FIG. 23 is a flow chart of processing to transmit data by 
the Intelligent Multicast communication protocol. This pro- 
tocol uses either pwnt-to-point or reliable broadcast proto- 
cols for each message depending upon the subject y"fl tt^ 
and how many subscriptions are open on this subject The 
choice of protocol is automatically made for each message 
depending upon how many subscribing processes/network 
addresses there are for the message at the time the message 
is published. If the number of subscribers for a subject 
changes sufficiently, the transmission protocol may change 20 
automatically. 

Step 600 represents the process of receiving a subscrip- 
tion request at the service layer of the data publishing 
process, passing this subscription along to the subscribing 
process and making an entiy for a new subsa^on in the 25 
subscription table. 

In step 602, a message is published by the service through 
the information layer to the service layer. The subject of tiie 
message may or may not be on the subject for which the new 
subscription was just entered. The service layer examines 30 
the subject data forwarded by the information layer about 
the message and coordinates with the infonnatioa layer to 
assign a TIB channel to the subject if the TIB channd was 
already assigned by the service and information layera of the 
subscribing process as symbolized by step 604. as 

In step 606» the service discipline compares the number of 
subscribers foe the subject of die message to a program- 
mable cutoff number wMch is based upon the cost of 
transmission point-to-point versus the cost of transmission 
by reliable broadcast The programmable cutoff number can 40 
be set and altered by the system administrator and is based 
upon any desired cost function, the nature of which is not 
critical to the invention. In the preferred embodiment, the 
cost function is comprised of a high water mark and a low 
water mark. If the number of subscribers is above the high 45 
water mark, the message will be scat by reliable broadcast. 
If the number of subscribers to this subject then subse- 
quently falls below the low water mark, subsequent mes- 
sages will be sent point-to-point. In some embodiments, the 
cost function can be an automatic learning program that so 
listens to the network and subsoiption requests and makes 
the decision based upon latency time or some other criteria 
of netwoik efEciency. 

Step 608 represents the process of calling the reliable 
broadcast protocol engine if the number of subscribers is 55 
greater than the cutoff number. The message is then put in an 
interprocess transfer mechanism directed to this protocol 
engine. 

If the number of subscribers is below the cutoff number, 
point-to-point transmission is more efficient so the service 60 
discipline calls the point-to-point protocol engine and puts 
the message into an int^process transfer mechanism 
directed to this protocol engine as symbolized by step 616. 

Step 612 represents the process of waiting for the next 
message or subscription and retiiming to step 600 if a 65 
subscription is received and to step 602 if another message 
is received. 
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In summary the concept of the invention is to use software 
l^ers to decouple plications from the conq>lexitie8 of the 
computer networic communication ait in ways that s^lica- 
tions have never before been decoupled. Fbr example, it is 
believed that the subject based addressing decoupling pro- 
vided by the information layer is new especially when 
coi^led with the service decoupling provided by the service 
layer. It is bdieved to be new to have extensible service and 
communication layers that can be easily modified by the 
addition of new service disciplines and protocol engines to 
provide service and configuration decoupling under chang- 
ing conditions such as new networit topologies and the 
addition of new or changed services and/or savers to the 
network. It is new to have a service layer that includes many 
Cereal service disciplines designed to enc^sulate many 
varied commimicati wi protocols. For example, these service 
disciplines can handle communication .with everything firom^. 
services like Iterate to operating system programs, other 
processes on other machines (or even the same machine or 
another part of the same process even) to a user sioing at a 
terminal. Further, the abilities of this service layer to imple- 
ment failure monitoring and recoveiy, distribution and rep- 
lication management, and security/access control services is 
new. 

Further, it is new to have the configuration decoupling and 
vahie added services of the communication layer. 

The teadnngs of the invention contemplate use of any one 
of these laym or any combination of the three in the various 
embodiments which togettier define a class or genus of 
software programs the species of \^di inclement the 
specific functions or comtdnations thereof defined herein. 

Appendix A» which can be found in the application file, is 
acomplete source code listing for the TIB™ communication 
interface software according to the teachings of the inven- 
tion in the C progranmnng language. Included axe all library 
programs, all interfaces and all l^ers of the software for 
both data publishing and data consuming processes. Also 
included arc all utility programs necessary to compile this 
software into machine readable code for a Unix'^^ based 
multitasking workstation. 

Tliere follows a more detailed specification of the various 
library programs and the ov^l structure and functioning of 
an embodiment of the conmiunication interface according to 
the teachings of the invention. 

Information Driven Architectore™, Teknekron Informa- 
tion Bus™, TTO™, TTOINFO™, TIBFORMSTm, Subject- 
Based Addressing™, and RMDF™ are trademarks of 
Ibknekron Software Systems, Inc. 

CONTENTS 

1. Introduction 

2. Tfeknekron Information Bus Architecture 

3. Reliable Maricet Data Protocol:RMDP 

4. Subject-Addressed Subscription Service:TEBINFO 

5. Data-exchange ComponentiTIBFORM 

6. Appendix: *man* Pages 
1. Introduction 

Tbe Teknekron Infonnation Bus™ software CHB™ com- 
ponent) is a distributed software conqKment designed to 
^ctlitate the exchange of data among afiplications executing 
in a real-time, distributed environment It is built on top of 
industry standard communication protocols (TCP/IP) and 
data-exchange standards (e.g., X.400). 

The document is oiganized as follows. Section 2 gives an 
architectural overview of theTEB™. Section 3 describes the 
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Reliable Market Data Protocol. This general purpose pro- 
tocol is particularly well suited to the requirements of the 
page-based market data services. It is also oiten used for 
bulletin and report distribution. Secdon 4 describes TIB- 
INFO, an interface supporting Subject-based Addressing. 5 
Secdon S describes a component and its interface that 
supports a very flexible and extensible data-exchange stan- 
dard. This component is called TIBFORMS. The Appendix 
contains (UNIX-like) manual pages for the core inteiiiaces. 

2. Architectural Overview |q 

2.1 Introductioa 

The Teknekron Information Bus (TIB™) is comprised of 
two mqor components: the (applicatioxi-Qriented) data com- 
municatUm oomponeat and the data-exchange component 
These are depicted in FIG. 2.1. In addition, a set of picsen- is 
tadon tools and a set of support utflities have been built 
around these (xmipqri^ assist the application deyelopa 
in the writing of TB™^ba^ 

The (applicadon-oriented) data oonununication compo- 
nent iiiq)lements an extensible framework for implementing ^ 
high-level, communication protocol suites. Two protocol 
suites have been implemented that are tailored toward the 
needs of fault-tolerant, real-time plications that conmui- 
nicate via messages. Specifically, the suites implement sub- 
scription services that provide communication support for ^ 
monitoring dynamically changing values over a network. 
Subscription services implement a connnunication paradigm 
well suited to distributing market data from, for mmple, 
(Juotron or Ttlerate. 

One of the protocol suites supports a traditional service- ^ 
oriented cooperative processing model. The other protocol 
suite directiy supports a novel information-oriented, co<^ 
erative processing model by in^lementing subject-based 
addressing. Using this addressing scheme, applications can 
request information by sutq'ect through a general purpose ^ 
interface. Subject-based addressing allowing information 
consumers to be decoupled £rom information producers; 
thereby, increasing the modulari^ and extensibility of the 
system. 

40 

Tlie application-oriented protocol suites are built on top of 
a common set of communication facilities called the dis- 
tributed conmninicatioris component, depicted as a sublayer 
in FIG. Zl. In addition to providing reliable conmiunica- 
tions protocols, this layer provides location transparency and 
network independence to its clients. 

Tlie layer is built on top of standaid transport-layer 
protocols (e.g., TCP/IP) and is cfqxtble of supporting mul- 
tiple transport protocols. Tlie data-exchange component 
implements a powerful way of representing and transmitting 50 
dam. AU data is encapsulated within self-describing data 
objects, called TIB™-fonns or, more commonly, simply 
forms. Since TTB™ forms are self-describing, tiiey admit the 
implementation of generic tools for data manipulation and 
display. Such tools include communication tools for sending 55 
forms between processes in a machine-independent format 
Since a self-describing form can be extended without 
adversely impacting die applications using it, forms greatiy 
facilitate modular application development. 

The two major components of TIB'™ were designed so 60 
that plications progranuners can use them indq)endentiy 
or togetiier. For example, forms are not only useful for 
oomnmnicating ^)plications thfl* share data, but also for 
non-communicating applications that desire to use the 
generic tools and modular programming techniques sup^ 65 
ported by forms. Such applications, of course, do not need 
die conunumcation sendees of the TTB^^. Sinulariy, appli- 
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cations using subject-based addressing, for example, need, 
not transmit forms, but instead can transmit any data struc-^-. 
ture. Note diat the implementation of the communication 
component does use fcnms, but it does not require applica- 
tions to use them. 
2.2 System Model 

The system model supported by Uie TIB™ consists of 
users, user groups, networks, services, service instances (or 
sen^), arid subjects. 

The concept of a user, representing a. human "end-user," 
is coflunon 10 most systems. A user is identified by a user-id. 
The TTB™ user-id is normally the same as the user-id (or 
logon id) supported by the underiying operating system, but 
it need not be. 

Each user is a member of a exactiy one group. The 
intention is that group should be composed of users with 
similar sayicc access pattCTns_and„access rights. Access . 
rights to a service system oiigi^^ at the level 

of users and al the level of groups. The system admirtisttator 
is responsible for assigning users to groups. 
. A network is a logical concept defined by the underiying 
transport layer and is supported by the TIB^. An applica- 
tion can send or receive across any of the networks that its 
host machine is attached to. It also supports all gateways 
functions and internetwork routing that.is supported by thp 
underiying transport-layer protocols. 

Since die lowest layer of the TTB'^^ communication 
component supports multiple networks, application-oriented 
protocols can be written that transparently switchover from 
one network to anodier in the event of a network failure. 

A service represents a meaningful set of functions that are 
exported by an application for use by its clients. Exan^les 
of services are an historical news retrieval service, a (^uotron 
datafeed, and a trade ticket router. An {plication wiU 
typically export only one service, although it can export 
many different services. 

A service instance is an application process enable of 
providing the given service. (Sometimes these are called 
"server processes.") For a given service, several instances . 
may be concunentiy providing it. so as to imiirove perfor- 
mance or to provide fault tolerance. Application-oriented 
communication protocols in the TTB"^ can implement the 
notion of a *fault-tolerant" service by providing automatic 
switchover from a failed service instance to an operational 
one providing the same service. 

Networks, services, and servers are traditional compo- 
nents of a system model and are implemented in one fashion 
or anoUier in most distributed systems. On the other hand, 
the notion ctf a subject is novel to die information model 
implemented by the TIB^. 

The subject space consists of a hieranchical set of subject 
categories. The current release of the TTB'"^ supports a 4 
level hierarchy, as illustrated by the following well formed 
subject: "equity.ibntcomposite.trade." Tlie TIB™ itself, 
enforces no policy as to the interpretation of the various 
subject categories. Instead, the applications have the free- 
dom and responsibility to establish convetitions on use and 
int^pretation of subject categories. 

Each subject is typically associated witii one or more 
services producing data about that subject Tlie subject- 
based protocol suites of the TIB™ are responsible for 
translating an application's request for data on a subject into 
communication connections to one or more service instances 
providing information on that subject 

A set of subject categories is referred to as a subject 
domain. The TIB™ provides support tor multiple subject 
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domains. This facility is useful, for example, when migrat- 
ing from one domain to another domain. Each domain can 
define domain-specific subject encoding functions for efS- 
dently representing subjects in message headers. 
2.3 Process Architecture 5 
The communication component of the TTB"^ is a truly 
distributed system with its functions being split between a 
frontend TIB'^Wcoimmmication library, which is linked with 
each application, and a bactend TIB^communication dae- 
mon process, for which there is typicsd^ one per host lo 
piocessor. This process architecture is d^icted FIG. 22. , 
Note that this fimctional split between TIB^ library and 
TIB'"' daemon is completely transparent to the application. 
In fEict, the application is completely unaware of the exist- 
ence of the TIB''** daemon, with the exception of certain ^5 
failure return codes. 

^ The TIB™ daemons cooperate among themselves to 
ensote refiabletlefEdent'onnmunication between machines. 
For subject-addiessed data, they assist in its efficient trans- 
mission by providing low-level system si^jport for filtering ^ 
messages by subject. 

The TrB™/communication library performs numerous 
functions associated with each of the application-oriented 
communication suites. For example, the library translates 
subjects into efficient message headers that are more com- ^ 
pact and easier to check than ASCn subject values. It also 
m^s service requests into requests targeted for particular 
service instances, and monitors the stams of those instances. 

The data-exchange component of TTB™ is implemented 
as a library, called the TEB^/formbTOTry, that is linked with ^ 
the application. This library provides all of the core func- 
tions of the data-exchange component and can be linked 
independently of the TIB™/communication library. The 
TIB™/form library does not require tite TIB™/communi- 
cation daemon. 

Z4 Communication Component 

The TIB™ Communication Component consists of 3 
subcomponents: the lower-level distributed communication 
component OXXO. and two high-level application-oriented 
communication protocol suites-the Market Data Subscrip- 40 
tion Service (MDSS), and the Subject-Addressed Subscrip- 
tion Service (SASS). 

The high-level protocol suites are tailored around a com- 
munication paradigm known as a subscription. In this para- 
digm, a data consumer "subscribes" to a service or subject, *5 
and in return receives a continuous stream of data about the 
service or subject until the consumer explicitiy tominates 
the subscription (or a failure occurs). A subscription para- 
digm is well suited for realtime ^plications that monitor 
dynamically changing values, such as a stock's price. In * 
. contrast, the more traditional request/reply conmiunication 
paradigm is ill-suited for such realtime applications, since it 
requires data consumers to "poll" data providers to learn of 
changes. 

The principal difference between the two high-level pro- 
tocols is that the MDSS is service-oriented and SASS is 
subject-oriented. Hence, for example, MDSS supports the 
sending of operations and messages to soidces, in addition 
to supporting subscriptions; whereas, SASS supports no 
similar functionality. 

2.43. Market Data Subscription Service 
2.4.1.1 Overview 

MDSS allows data consunra to receive a continuous 
stream of data, tolerant of failures of individual data sources. 65 
This protocol suite provides mechanisms for administering 
load balancing and entiUement policies. 
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Two properties distinguish the MDSS protocols from the 
typical client/server protocols (e.g. RFC). First, subscrip- 
tions are explicitiy supported, v^iereby changes to requested 
values are automatically propagated to clients. Second, 
clients request (or subscribe) to a service, as opposed to a 
server, and it is the responsibility of die MDSS component 
to fcffward the client's request to an available server. The 
MDSS is then responsible for monitoring the server con- 
nection and reestablishing if it fails, using a different server, 
if necessary. 

The MDSS has been designed to meet the following 
ixapottaat objectives: 

(1) Fault tolerance: By supporting automatic switchover 
be^een redundant services, by explicitiy supporting dual 
(w triple) networks, and by utiliztng tiie fault-tolerant trans- 
mission protocols imi^emented in die DCC (such as the 
"reliable broadcast protocols")* the MDSS ensures tiie integ- 
rity of a subscription againsit aU single point' failures. An 
inopportune Mure may temporarily disrupt a subscription, 
but the MDSS is desired to detect faHuies in a timely 
fashion and to quickly search for an alternative communi- 
cation path and^or server, Recovery is automatic as well. 

(2) Load balancing. The MDSS attempts to balance the 
load across all operational servers for a service. It also 
rebalances the load when a server fails or recovm. In 
addition, the MDSS supports server assignment policies that 
attempts to optimize the utilization of scarce resources such 
as "slots" in a page cache or bandwidth across an ext^nal 
communication line. 

(3) Network efficiency. The MDSS supports the intelli- 
gent multicast protocol implemented in the DCC. This 
protocol attempts to optimize the limited resources of botii 
network bandwidth and processor I/O bandwidtii by provid- 
ing automatic, dynamic switchover from point-to-point 
conmmnication protocols to broadcast protocols. For 
example, the protocol may provide point-to-point distribu- 
tion of Iblerate page 8 to the first five subscribers and then 
switch all subscribers to broadcast distribution when the 
sixtii subscriber appears. 

(4) High-level communication interface. The MDSS 
implements a simple, easy-to-use plication developmetit 
interface that mask iiK)st of the complexities of program- 
ming a distributed ^stem, including locating servers, estab- 
lishing communication connections, reacting to failuies and 
recoveries, and load balancing. 

2.4.1.2 Functionality 

The MDSS supports the following core functions: 
get MDSS establishes a fault-tolerant connection to a 
server for tiic specified service and "gets" (i.e., 
retrieves) the current value of die specified page or data 
element The connection is subscription based so that 
updates to the specified page are automatically for- 
warded 

halt 'lialt" the subscription to the specified service. 

derive sends a modifier to the server that could potentially 
change die subscriptioa 

The MDSS protocol has been high-optinuzed to support 
page-oriented maiket data feed, and this focus has been 
reflected in the choioe of function names. However, the 
protocol suite itself is quite general and supports the distri- 
bution of any type of data. Consequentiy, tiie protocol suite 
is useful and is being used in other contexts (e.g., data 
distribution in an electronic billboard). 2.4.2 Subjea-Ad- 
drcssed Subscription Service (SASS) 2.4.2,1 Overview 

The SASS is a sophisticated protocol suite providing 
application developers a very high-level communications 
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interface that fully supports the informalion-oiieiited, coop- 
erative processing model. This is achieved through the use 
of subject-based addressing. 

The basic idea behind subject-based addressing and the 
SASS's implemmtation of it is straightforward. Whenever 
an application reqimes a piece of data, especially, data that 
represents a dynamicaUy changing value (e.g. a stock price), 
the plication simply subscribes to that data by spedfying 
the appropriate subject For example, in order to receive all 
trade tickets on IBM, an ^plication may issue the following 
subscription: *trade_ticketJBM* *. Once an s^plication has 
subscribed to a particular subject, it is the re^onsibility of 
the SASS to choose one or more service instances providing 
icformatira on that subject Tlie SASS then inakes the 
^piopriate communications connections and (c^tionally) 
notifies fhe service instances providing the information. 

The SASS has been designed to meet several important 
qbjectiyes: 

(1) Decbiq)iing information consumers from infcninatioa 
providm. Through the ase of subject-based addressing, 
infomiation consumers can request iidbrmadon in a way that 
is independent of the application producing the infonnation. 
Hence, the producing application can be modified or siq)- 
planted by a new s{)plication providing die same infonnation 
without Meeting the consumers of the infonnation. 

(2) EflBdency. Support fbr filtexing messages by subject is 
buUt into the low levds of theTIB''^ Hawn^^ where it can 
be very efficient Also, tbe SASS suppoits filtering data at 
the producer side: data that is not amently df interest to any 
sppltcation can simply be discarcled prior to placing in on the 
networic; thereby, conserving network bandwidtii and pro- 
cessor I/O bandwidth. 

(3) High-level communication mterface. The SASS inter- 
face gready reduces the complexities of programming a 
distributed application in three ways. Fust, the consumer 
requests infonnation by subject, as opposed to by server or 
service. Specifying infoimadon at this level is easier and 
more natural than at the sovice level. Also, it insulates the 
program from dianges in service providers (e.g., a switch 
firan IDN to Ticker 3 for equity prices). Second, the SASS 
presents all data through a simple uniform interface-a pro- 
grammer needing information supplied by three services 
need not learn three service-specific protocols, as he would 
in a traditional processing model Third, the SASS auto- 
mates many of the hard or error-prone tasks, such as 
searching for an ^ipropriate service instance, and establish- 
ing the correct communication connectioit 

2.4.2.2 Functionality 

For a data consumer, the SASS provides three basic 
functions: 

subscribe where the consumer requests information on a 
real-time basis on one or more subjects. The SASS 
components sets up any necessary communication con- 
nections to ensure that all data matching the given 
subject(8) will be delivered to the consimier. The con- 
sumer can specify that data be delivered dtiier asyn- 
chronously (interrupt-^ven) or synchronously. A sub- 
scription may result in the producer service instance 
being informed of the subscription. This occurs when- 
ever the producer has set up a registration procedure for 
its service. This notificaticm of the producer via any 
specified registration procedure is transparent to the 
consumer. 

cancel which is die opposite of subscriba The SASS 
component grace&Uy closes down any dedicated com- 
munication channels, and notifies the producer if an 
^propriate registration procedure exists for the ser- 
vice. 
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receive receive and "callbacks" are two different ways for 
applications to receive messages matching their sub- 
scriptions. Callbacks are asynchronous and support the 
event driven programming style-a style that is paiticu- . 
larly well-suited for applications requiring realtime 
data exchange. ''Receive'* supports a traditional- syn- 
chronous interface for message receipt 

For a data producer, the SAS S provides a coiiq)lenientaiy set 

of functions. 

Note that an application can be both a producer and a 
consumer with respect to die SASS, and this is not uncom- 
mon. 

2.4.3 Distributed Comamnicadon Component 
14.3.1 Overview 

The Edstribated Communication Component (DGQ pro- 
vides commumcation services to higher-level proto- 
cols, in particular, it provide several ty^ of fault transpar- 
ent protocols. " 

The DCC is based on several important objectives: 

(1) The provision of a simple, stable, and uniform com- 
numication model. This objective oSers several boiefits. 
First, it offiers increased progranuner productivity by shield- 
mg developers from the complexities of a distributed envi- 
nmment; locating a target process, establishing communi- 
cations with it, and determirung when something has gone 
awry arc all tasks best done by a C2q)able communications 
infrastructure, not by the programmer. Second, it reduces 
development time, not only by increasing programmer pro- 
ductivity, but also by simpl^ing the integration of new 
features. Finally, it enhances configurabilily by keeping 
applications unaware of the physical distribution of other 
components. This prevents developers from building in 
dependencies based on a particular physical configuration. 
(Such dependencies would complicate subsequent redon- 
figurations.) 

(2) PcHtability through encapsulation of isqxntant system 
structures. This objective achieves importance when migra- 
tion to a new hardware or software environment becomes 
necessary. The effort expended in shieidit^ applications 
from the specific underiying communication protocols and 
access methods pays ofiF handsomely at that time. By iso- 
lating the reqmred changes in a small portion of the system 
(in this case, the DCQ, applications can be ported virtually 
unchanged, and the firm's appHcation investment is pro- 
tected. 

(3) EfiScicncy, TTus is particular important in this compo- 
nent To achieve this, the DOC builds on top of less costiy 
"coimectionless" transport protocob in standard protocol 
suites (e.g., TCP/IP and OSI). Also, the DCC has been 
carefully designed to avoid the most costiy problem in 
protocols: the proliferation of data **copy" operations. 

The DCC achieves these objectives by implementing a 
layer of services on top of the basic services provided by 
vendor-supplied software. Rathv than re-mventing basic 
functions like reliable data transfer or flow-control mecha- 
nisms, the DCC concentrates on shielding applications from 
the idiosyncrasies of any one particular operating system. 
Examples include the hardware-oriented interfaces of tbe 
MS-DOS environment or the per-process file descriptor 
limit of UNIX. By providing a single, unified conununica- 
tion tool Uiat can be easily replicated in many hardware or 
software environment, tite DCC fulfiUs the above objectives. 

2.4.3.2 Furictionality 

The DCC inqilements several different transmission pro- 
tocols to support the various interaction paradigms, fault- 
tolerance requirements, and performance requireanents 
imposed by die high-level protocols. Two of die more 
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interesting protocols are reliable broadcast and intelligent 
multicast protocols. 

Standard broadcast protocols are not reliable and are 
unable to detect lost messages. The DCC reliable broadcast 
protocols ensure that all operational hosts dtfaer receive each 5 
broadcast message or detects the loss of the message. Unlike 
many so-called reliable broadcast protocols, lost messages 
are retransmitted on a limited, periodic basis. 

The intdligent multicast protocol inovides a rdiable 
datastream to multiple destinations. The novel aspect of the 10 
protocol is that it can dynamically switch from point-to pmnt 
transmission to broadest transmission in order to optimize 
the network and processor load The switch from point-to- 
point to broadcast (and vice versa) is transparent to higher- 
level protocols. This protocol admits the support of a much 15 
larger number of consumers than would be possible using 
dther point-to-point or broadcast alone. The protocol is built . . 
on top of other protocols within the DCC. 

Currently, all DCC protocols exchange data only in dis- 
crete units, i.e., ''messages" (in contrast to many Transport 20 
protocols). TTie DCC guarantees that the messages originat- 
ing from a single process are received in the order sent 

The DCC contains fault-tolerant message transmission 
protocols that support retransmission in the event of a lost- 
message. The package guarantees ''at-most-once" semantics 2S 
with regards to message delivery and makes a best attempt 
to ensure ^'exactly once" semantics. 

The DCC contains no exposed internees for use by 
application developers. 

3. RELIABLE MARKET DATA PROTOCOL 30 

3.1 Introduction 

The Reliable Market Data Pkotocol (RMDP) defines a 
programmatic interfece to the protocol suite and services 
comprising die Market Data Subscription Service (MDSS) 
HB'^^subcon^xmenL RMDP allows market data consumers 35 
to receive a continuous stream of data, based on a subscrip- 
tion request to a given service. RMDP tolerates fuhires of 
individual servers, 1^ providing facilities to automatically 
leconnect to alternative servers providing the same service. 
All the mechanisms for detecting server failure and recov- 40 
ery, and for hunting for available servers are implemented in 
the RMDP library. Consequently, application programs can 
be written in a simple and naive way. 
- The protocol provides mechanisms for administering load 
balancing and entitlement policies. For example, consider a 45 
trading room with three Tderate lines, lb maximize utili- 
zation of the available bandwidth of those Tblerate lines, the 
system administrator can "assign" certain commonly used 
pages to particular servers, ie.. page 5 to server A, page 405 
to server B. etc. Each user (or user group) would be assigned 50 
a "default" server for pages which are not explicitly preas- 
signed. (These assignments are recorded in the TIB'^ Ser- 
vices Directory.) 

lb accommodate failures, pages or users are actually 
assigned to prioritized list of servers. When a server expe- 55 
riences a hardware or software failure, RMDP hunts for and 
connects to the next server on the list When a server 
recovers, it announces its presence to all RMDP cHents, and 
RMDP reconnects the server's original clients to it. (Auto- 
matic reconnection avoids situations where some servers are 60 
overioaded while others are idle.) Except for status mes- 
sages, failure and recovery reconnections axe transparent to 
the application. 

The MDSS protocol suite, indudii^ RMDP, is built on 
top of the DOC and utOizes the reliable communication 65 
protocols implemented in that conqionent In particular, the 
MDSS suite utilizes the reliable broadcast protocols and the 
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intelligent multicast protocol provided therein. RMDP sup- 
ports both LANs and wide area networks (WANs). RMDP 
also supports dual (or multiple) networks in a transparent 

fashion. 

RMDP is a "service-addressed'* protocol; a complemen- 
taiy protocol, TIBINFO, supports "subject-based address- 
ing." 

3.2 Programmatic Interface 

RMDP programs are event-driven. All RMDP function 
calls are non-blocking: even if the call results in communi- 
cation with a server, the call returns immediately. Server 
responses, as well as error messages, are returned at a later 
time through an application-supplied callback procedure. 

The principal object abstraction implemented in RMDP is 
that of an Rstream, a *Yeliable stream," of data that is 
associated with a particular subscription to a specified 
service. Although, due to fiailures and recoveries, different 
servers may provide the subscription data at different times, 
the Rstream implements the abstraction of a single unified 
data stream. Except for short periods during failure or 
recovery reconnection, an Rstream is connected to exactly 
one server for the specified service. An application may open 
as many Rstreams as needed, subject only to available 
memory. 

An Rstream is bidirectional — particular, the RMDP 
Ghent can send control commands and messages to the 
connected server over the Rstream. These commands and 
messages may spur responses or error messages firom the 
server, and in one case, a coounand causes a "derived" 
subsaiption to be generated. Regardless of cause, all data 
and error messages (whether remotely or locally generated} 
are delivned to the client via the ai^iropiiate Rstream. 

The RMDP interface is a narrow inteiftce consisting of 
just six fonctions, which are described below. 
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nxulp_5etFtup(propeny, value) 
xnu^_prop^t propeity; 
Cttldr^t value; 



Used to set the values of RMDP properties. These calls 
must be made before the call to Emc^^InitQ. Required 
properties are mariced with ? in the list below. Other prop- 
erties are optional The properties currcndy used are: - 

*RMDP_CALLBACK 

Pointer to the callback function. See the description of 
callback below. 

rmdp_servic:e3iap 

The name of Services Directory to be used in lieu of the 
standard directory. 

RMDP^GROUP 

The user group used to determine the appropriate server 
list Should be prefixed with Default is group is "+" (i.e. 
the null group). 

RMDP__RErRY_TIMB 

The number of seconds that the client will wait between 
successive retries to the same server, e.g., in the case of 
cache full." Default is 30. 
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RMDP^QmET-TIME 



The time in seconds that a stream may be "quiet** before 
the protocol assumes that the server has died and iTnTifltft^y a 
"hunt" for a dtfTerent server. Default is 75. 

. RMDP_VERnnr_TIME 

The time in seconds between successive pings of the 
server by the client Default is 60. 

RMDP_>\PP_NAME 

The name of the application i.e. "telerate", **reutcrs" etc. 
If this property is set, then the relevant entries from the 
Service Directory will be cached. . 



Ibis imtializes the internal data stiuctnres and must be ^ 
called piior to any caDs to nndp_GetO. 



im^^Oet^ervioe, leqaest, host) 



25 



This is used to get a stream of data for a particular 
'service* and subscription 'request*. For the standard market 
data services, the request will be the name of a page (e.g., 30 
**5**, "AANhT). If 'host* is non-NULL, then the RMDP will 
only use the server on the given hosL In this case, no 
reconnection to alternative servers will be attempted upon a 
server failure. If 'host* is NULL, then RMDP will consult the 
TEB*^ Services Directory to identify a Ust of server alter- 35 
natives for the request, 'rstream' is an opaque value that is 
used to refer to the stream. All data passed to the applica- 
tion's callback function will be identified by this value. 

An cnor is indicated by RScream rstream = NULL. 
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Id; 
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This generates a new subscription and, hence, a new 
'Rstream* from an existing subsciiptioa *conunand* is a 
string sent to the server, where it is interpreted to determine 
the specific derivadoa 

Tbe standard maricet data servers understand die follow- 
ing commands: "n** for next-page, "p" for previous-page and 
**t XXXX" for time-page. 

Derived streams cannot be recovered in the case of server 
failure. If successful, an Rstream is returned, otherwise 
NULL is returned. 



void 

nndlp__Mcasage(rstrcain, mag) 
RStreaiiu mcam; 
char *insg'i 



Si 
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the server's network address. Some messages induce a 
response from the server (such as queries). In this case, the 
response will be delivered to all streams that are connected 
to the server. 



void 

niid^_|Ialt(r8tECam) 
RStr 
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This gracefully halts die 'rstream*. 



vdd 

cal ftackCffttemi , msgtype, msg, act.'eir) 

RSbccaiuiBUciiiu; 

nidp irwg t msgtype; 

•msg; 



T!vfp_m__t 



This is the callback function which was registered with 
rmdp_SttProp(RMDP__CALLBAaC, callback), 'rstream* 
is the stream to which die message pertains, 'msgtype* can 
be any of die values defined below (see "RMDP Message 
lype'O. *msg* is a string which may contain vtlOO compat- 
ible escape sequences, as in MDSS. (It will NOT however 
be prefEuxd with an ''[[... E. That role is assumed by the 
parameter "msgtype' .) 

The last two parameters are only meaningful if 'msgtype* 
is MDP_MSG__STATUS. 'act' can be any of the values 
found in 'TIMDP Acdon Type** (see below), but special 
action is necessary only if act ='MDP_ACT_CANCEL*. 
The latter indicates that the stream is bdng canceled and is 
no longer valid. It is up to the application to take appropriate 
action. In ei±er case, 'err* can be any of the values found in 
"RMDP Error Type** (see bdow), and provides a description 
of die status. 

RMDP Message Types (mdp__miB^t) 

The message types are listed below. Tliese types are 
defined in the underlying (unreliable) Market Data Protocol 
(MDP) and are exported to the RMDP. 
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MDP_MSa_3AD = -1 




MDP_3ISG_DATA = 0 


Page data message. 




Statua/enor message. 


MDP_MSO_OOB = 2 


"Ont of Band" message, e.g^ 






MDP_MS0_QUERy»3 


Qociy icsiilt. 
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RMDP Acdon Type (mdp_act„t) 

The action types are listed below. These action types 
inform the RMDP clients of activities occurring in the lower 
level protocols. Generally speaking, they are 'foe your 
information only^ messages, and do not require additional 
actions by the RMDP client The exception is die '*MDP_ 
ACT_CANCEL*' action, for which there is no recovery. 
These types are defined in the underiying (unreliable) Mar- 
ket Data Protocol (MDP) and are exported to the RMDP. 



Sends die string 'msg* to die server used by 'istteam' . The 
messages are passed diiecUy to die server, and ate not in any 
way affected by die state of die stream. The messages are €S 
understood by die standard maiket data seivm include "ir 
<f AGE NAME>'' to rerequest a page, and "q a" to request 



MDP^cr_OK=o 

MDP_ACT_CANCELs= I 



No tnmsDal *yf'rfT^ rpQuinsdi 
Hie request caxmot be. 
serviced, cancel the stream, 
do not attenqn to lecomiecL 
(Eg., invalid page name.) 
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•continued 



MDP_ACr_C30NN_FIRST = 2 



MDP^Cr_CONN_NE>Cr = 3 



MDP_ACr.aArERo4 



MDP«ACTJlBrRYo5 



The senrer is closmg the 
ttream; ibs fint server in the 
flltemativBS list is beiog 
tried (Eg^ the server is 
rf^fting "extra** g^gntt for 
load balanciiig.) 
The server is dosiog the 
stxesm; the next server in the 
flUanatives list is being 
tried (Kg^ the server^s Hne 
to host Sails.} 
Server j'*"""^ service re- 
quest at this lime; win le- 
Bubnit lequBSt IstBi; or tiy a 
difGncnt server. (E^g.* 
Cache fbO.) 

Request is beiog ictried 
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is^orf jninori .<)iuJli£cT 1 [.<iiuJifier21)] 

where and *Y are metacharacters that delimit an opdonal 
component major, minor, qualifierl and qualifieT2 are called 
subject identifiers. A subject identifier is a string consisting 
of the printable asdi characters exchiding \\ *?', and A 
subject identifier can be an empty string, in which case it will 
mabdb with any subject identifier in that position. The 
complete subject, including the */ separators, cannot exceed 
32 characters. Sutgects are case sensitive. 

Some example of valid subjects are listed below: The 
comments refer to the inteipretation of subjects on the 
consume side. CThe publish-side semantics are slightly dif- 
ferent) 



RMDP Error T^pes (m<^)_cn__t) 

Description of error, for logging or n^rting to end user. 
These types are defined in the underlying (unreliable) Mar- 
ket Data Protocol (MDP) and are exported to the RMDP. 



MDP_ERR_OK = 0 25 

MDP_mL-LOW = 1 

MDP_ERR_QUIET « 2 

MDP_£RILJNVAL = 3 

MDPJRiLJlESRC = 4 

MDPJRHJNTCRN AL « 5 

MDP_ERILJ)ELAy = 6 

MDP JERIL_SYS = 7 

MDP_JERIU00MM=»8 



4. Subject-Addressed Subscription ServicerHBINFO 

4.1 Introduction 35 
TIBINFO defines a programmatic interface to the proto- 
cols and services comprising theTIB^ subcomponent pro- 
viding Subject-Addressed Subscription Services (SASS). 
The TIBINFO interface consists of libraries: TIBINFO_ 
CONSUME for data consumers, and nBINFO^PUBUSH 40 
for data providers. An application includes one library or the 
other or both depending on whether it is a consumer or 
provider or both. An q>plication can simultaneously be a 
consumer and a producer. 

Through its support of Subject-Based Addressmg, TEB- 
INFO siq)poits a ix^otmation-oriented model of co(q»erative 
processing by providing a method for consumers to request 
infbnnation in a way that is mdependent of the service (or 
services) producing the information. Consequentiy, services 
can be modified or replaced by alternate services providing 
equivalent information without impacting the information 
consumers. Hiis decoupling of infonnation consumers from 
infonnation providers permits a higher degree of modular- 
ization and fiexibility than that peimitted by traditional 
service-oriented processing models. 

For Subject-Based Addressing to be useful in a real time 
environment, it must be efficiently implemented. With tiiis 
objective in mind, support for Subject-Based Addressing has 
been built into the low levels of the Distributed Communi- ^ 
cations Component In particular, the filtering of messages 
by subject is performed witiun the TtB^i^ daemon itself. 

4.2 Concepts 

Subject ^ 

The subject space is hierarchical. Cuirentiy, a 4-level 
hierarchy is supported of the following format: 



equityibnLConi]X)site.quote 

e4^Qr..conq)osIte>^ote matches any minor subject 

gqirity.ibm fp«»/4t^ any quaHfis'l and 

Qu8lificr2 

eqniQribnL same as dsove 



Within tiie TIBINFO and the SASS, subjects are not 
interpreted. Hence, applications are free to establish con- 
ventions on the subject space. It should be noted tiiat SASS 
components first attempt to match the major and minor 
subject identifiers first As a consequence, although ^pli- 
cations can establish the convention that "equityibm" and 
"..equity.ibm*' are equivalent subjects, subscriptions to 
''equityibm" will be more efficiently pirocessed. 

Stream 

A stream is an abstraction for grouping subscriptions. The 
subscriptions on a stream share a common set of properties, 
notably the same message handler (i.e., "callback** routine) 
and the same error handler All subscriptions on a stream can 
be "canceled" simply by destroying the stream. 

A stream imposes littie overiiead on the systent Tliey can 
tiierefore be freely mated and destroyed. 

Protocol Engines, Service Disciplines, and Subject 
Mappers 

The SASS and DCC components implement many sup- 
port services in order to provide the functionality in TIB- 
INFO. These include subrject m^peis for efficientiy han- 
dling subjects, service disciplines for controlling the 
mteraction with servers, and protocol engines for imple- 
menting reliable communication pnHocols. TIBINFO pro- 
vides an interface for setting properties of these components. 
Hence, by setting the ^propriate properties, one can specify, 
fijT example, die bdiavior of the subject m^jper through the 
TIBINFO interface. Since these properties are in configu- 
ration files, configuration and site dependent parameters can 
be altered for the above components by the system admin- 
istrator tiuDugh TIBINFO. 

In some embodiments, the property defiiutions for TIB- 
INFO and for the underiying components may be augmented 
to sui^)ort enhancements. This use of properties yields 
flexibility and extensibili^ within the confines of a stable 
functional interface. 

4.3 Description 

The TIBINFO interface is high-level and easy to use. 
Published data can be a form or an uninterpreted byte string. 
Messages can be received either m a synchronous fashion. 
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or in an asynduonous fashion ttat is suitable for event- 
drivoi programming. The following functions aie sufSdeiit 
to write sophisticated consumers using event-driven pio- 
gronuning. 
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The following functions are sufficient to write producers. 
IVo publishing fimcdons are provided to support the dif- 
ferent data types that can be transmitted through the TIB-^ 
INFO interface. 



lib^stream *tib__consume_create(property-iist, 
TEB_EOP) 

Creates a TIBINPO stream that supports multiple sub- 
scriptions via the ''subscribe" function. The property ^Ust is 
a (possib^ empty) list of property value pairs, as illustrated 

by 



10 



tib_ptthlish__create(property-list» TIBJEOP) 

Is used to create an TffilNFO stream for publishing 
records. The propeity_list is a (possibly emp^} list of 
property-value pairs, as illustrated by 



tib_^piibfish_creiitBCnB_FROP_ERRHANDI£iUny-^^ 



d1>_.eoiiiiiine_a8ate(nBJPROPJi4SGHANDLER, 

"*y_handlfir, 

TIB_pROP JERRHANDLER, xxiy_jBRLjnndla; TlB_pOP); 



Valid properties are defined below. TIB_EOP is a literal 
signaling the end of the property list 
30 

void tib_dcsiiD|y^izBfliii) 
'nb_8tceam *&ljefliii; 



Reclaims resources used by the specified stream. 



Itb.jcxrarcode tib__$ubsczibe(itieBii^ sutgect. dieanldatH) 
Tib_8objcct *subjcct; 

caddr_t rltwitrfafw; 



Informs the TIB™ software that the dient application is 
interested in messages having the indicated subject If 
stream has an associated "message-handler,** then it wiU be 
called whenever a message satisfying the subscription 
arrives. Qualifying messages are delivered on a first-in/ 
first-out basis. The value of clientdata is retumed in every 
message satisfying the subscription subject. Note that mul- 
tiple subscriptions to the same subject on the same stream 
are imdefined. ^ 



vdd lib_Gaii06l(slicaiD) 
Hb^^trem *iiiCHiii; 

Cancels the client ^plication's subscription to the speci- 
fied subject 



void iny_ii]essageLjiandlcr(sBeanxnBg) 
Tib_8tream *stream; 
Tfb^jataagt ^message; 



Tins is the ''callback*' function that was registered with 
the stream. Forms are retumed unpacked. The function can 6S 
reference the entire message structure dirough the macros 
described below. 



Valid properties are defined below. TEB^EO? is a con- 
stant signaling the end of the property list 



tib_de$tioy(8tTe&ix^ 

Hb_StXtB&Ul tttCSQli 



Reclaims resources used by the specified streauL 



TtbL^coratoode tib_piibifislL.fiiixo(itresiiv sufaject, fonn) 
Tih.jBtiesiii ^stfcsmi 
Tib^solgect ^subject; 
Fonn fonn^ 



Accepts a single. Whacked form, packs it, and publishes 

it 



'nb_etrorcode db^^nbHslLJbiificiiCttnaiii, sul^ecti lengtfii 
fomi) 

Ttb.strcam *MiBai[i; 
TEb^tubfed ^subject; 
short tengtfa; 
Fomi ibnnj 



Accepts a byte buffer of specified length and publishes it 
The remaining functions are control functions that apply 
to both the consume and the publish side. 

void Tib_batchO 

This may be used prior to initiating multiple subscrip- 
tions. It informs die TIB™ Hbraiy that it can delay acting on 
the subscriptions until a tib^unbatch is seen This allows the 
TIB™ library to attempt to optimize the execution of 
requests. Note that no guarantees are made about the order- 
ing or timing of "hatched" request In particular, (i) requests 
may be executed prior to die receipt of the tib_unbatch 
function, and (ii) the effects of changing properties in the 
ntiddle of a hatched sequence of requests is undefined. Batch 
and unbatch requests may be nested. (Note that the use of 
tib_.batch is completely optional and it does not chaiigie the; 
semantics of a correct program.) 



Hb^exrarcode Qb_streain_jwt(atream, piopeity, vabe) 
T[b__9tre8iD *&ti6Bni; 
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-continued 



caddr_t Tfllne; 
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TIBINFO Message Structure 



The component infonnation of a TIBINFO message can 
be accessed through the foUowiiig macros: 



Used to change the dynamicaBy settable properties of a 
stream. These properties are described below. Note that 
some properties can only be set prior to stream creation (via 
tib_defaiilL.set) or at stream creation. 



Iil)_msg_clicmdaia(in5g) 
tib_jnsg_jabject(msg} 
tib__msg_si2c(m^ 
tib_jnsg_va}uc(ixisg) 
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caridr_t tib_sireflm_get(stream, propoty) 



Used to retrieve the current vahie of the specified prop- 
erty. 



Tib_crrorcode tib_dcfeult_s«( proper^ value) 
Hb^^treaxQ ^stream; 
"nb^jpropcfty *{uopcxty! 
caddr_t value; 
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Used to change the initial properties of a stream. During 
stream creation, the default values are used as initial values ^ 
in the new stream whenever a property value is not explicitly 
specified in the creation arg;uinent list 



Tn>_eraccode tib_defiailL.8iBt( prepexty) 

m_ 
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THiL-piopcfty ^properly; 



Used to retrieve the de&ult value of the specified prop- 
Bity. 35 



tib_unbatchO 

Informs TIBINFO to stop 'liatching" functions and to ^ 
execute any outstanding ones. 



TIBINFO Attributes 
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The properties defined by TIBINFO and their allowable 
values are listed below and are described in detail in the 
expropriate **man*' pages. The last grouping of properties 
allow the programmCT to send default property values and 
hints to the underiying system components-spedfically, the ^ 
netwodc protocol engines, the TIB*™ subject mapper, and 
various service disciplines. 



TIB_PROP_CFILE 

TIB_PROP_CIJENTDArA 

TIB_J»ROP_JBRRHANDLER 

TIB_PROP_tASTMSG 

TIB_J>R0P_31SGHANDLBt 

TIB_PROP_NErWORK 

TIB_PROP_NErW0RK_CFlLE 

TIB_PROP,^SERVrcE 

TIB_J*ROP_SERVICE_CFE£ 

TIB_PROP_SUBJECT 
TIB_PROP_SUBJECr_CFILE 



cfilc-handlc 
pointer 

QTHr-h n n^fif-liOHy 

tib_in6SSQS9 pointer 



ptoiociJ-iiiigliift'^iropeity-Hst 
cfik 

scrvice-discipHiifi-pnipcfty* 
fist 

service-discipfiiie-pnipcrt)^ 
cfile 

subject*propeity4ist 
subjcct-propcny-cfilc 
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The following macros rctum TRUE (1) or FALSE (0): 



tib-JM8,J^_lwiffer(iing) 
tib_jiisg_js_J'axin(iiisg) 
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5. TIB™ Forms 
5.1 Introduction 

The Forms package provides die tools to create and 
manipulate self-describing data objects, e.g., forms. Fbrms 
have sufficient expressiveness, flexibility and efficiency to 
describe all data exchanged between the different TIB™ 
applications, and also between the main software modules of 
each i^licatioa 

The Forms package provides its clients with one data 
abstraction. Hence, the software that uses the Forms package 
deal with only one data abstraction, as opposed to a data 
abstraction for each different type of data that is exchanged. 
Using forms as the only way to exchange user data, facili- 
tates (i) the integration of new software modules that com- 
inimicate with other software modules, and (ii) modular 
enhancemem of exisdng data formats without die need to 
modify the underiying cod& Tliis resulte in software that is 
easier to understand, extend, and fnginf^ ^fa, 

Farms are the principal shared objects in the TIB™ 
commtmicadon infrastructure and implications; conse- 
quently, one of the most important abstracdons in the TIB™. 

Hie primary objective in designing the forms package 
were: 

Extensibility — ^It is desirable to be able to change the 
definition of a form class without recompiling the appli- 
cation, and to be able introduce new classes of forms into 
the system. 

Maintainability-^orm-class definition changes may affect 
many workstations; such changes must be propagated 
systematically. 

Expressiveness — ^Forms must be capable of describing com- 
plex objects; therefore, the form package should support 
many basic types such as integer, real, string, etc. and also 
sequences of these types. 

Efficiency — Forms should be the most common object used 
for sending information between |HX)cesses-both for pro- 
cesses on the same woricstation and for processes on 
different workstations. Hence, forms should be designed 
to allow the communication infirastxucture to send infor- 
mation effidentiy. 

Note that our use of the term 'form" differs from die 
standard use of die term in database systems and so-called 
"forms management systems.*' In diose systems, a 'Yonn** is 
a format for displaying a database or file record. (Typically, 
in such systems, a user brings up a form and paints a 
database record into die farm.) 

Our notion of a form is more fundamental, akin to such 
basic notions as record or array. Our notion takes its mean- 
ing from the original meaning of the Latin root word forma. 
Bonowing from Webster '*The shape and structure of 
something as distinguished from its material". Forms can be 
instantiated, opoated on, passed as arguments, sent on a 
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network, stored in files and databases. Their contents can 
also be displayed in many different formats, 'templates" can 
be used to specify how a form is to be displayed. A single 
foim (more precisely, a form class) can have many ''tem- 
plates" since it may need to be displayed in many different ^ 
ways. Different kinds df users may, for example, desire 
different formats for displ^ing a form. 

5.2 Desoiption 

Forms aie self-describing data objects. Each form con- iq 
tains a reference to its formclass, which completely 
describes the form. Forms also contains metadata that 
enables die fom packagc to perform most operations with- 
out accessing the related formdass definition. 

Each form is a member of a specific form dass. All forms 
within a dass have the same fields and fidd*s labels (in fact, . 
all defining attributes are identical among the forms of a 
spedfic class). Each form dass is named and two dasses ate 
consideied to be distinct if diey have disdna names (even 20 
though the dasses may have identical definitions). Althou^ 
the forms software does not assign any spedal meaning or 
processing support to particular form names, the applica- 
tions using it might (In £act, it is expected diat certain form 
naming conventions will be establi^ed.) 25 

There are two main classification of forms: primitive 
versus constructed forms, and fixed leqgth versus vaiiable . 
size forms. 

Primitive farms are used to represent primitive data types 
such as integers, float, strings, etc. Ptimitive forms contain ^ 
metadata, in the form header information header and the data 
of the Impropriate type, such as integer, siring, etc 

Qmst n icted forms contahi sub-forms. A constructed form 
contains other forms, which in turn can contain subforms. 

Fixed length forms are simply forms of a fixed length, ^ 
e.g., all the forms of a fixed length class occupy the same 
number of bytes. An exan^le for a fixed length primitive 
form is the integer form class; integer forms always take 6 
bytes, (2 bytes for the form header and 4 bytes for the integer ^ 
data). 

Variable size forms contain variable size data: variable 
size, primitive forms contain variable size data, sudi as 
variable length string; variable size, constracted fonns con- 
tain a variable number of subforms of a single class. Such 45 
fiorms are similar to an anray of dements of the same type. 

5.3 Qass Identifiers 

When a class is defined it is assigned an identifier. This 
identifier is part of each of the class's form instance, and is 
used to identify the form's dass. Hiis identifier is in addition ^ 
to its name. Class identifiers must be unique within their 
context of use. Class identifiers are 2 bytes long; bit 15 is set 
if the class is fixed length and cleared otherwise; bit 14 is set 
if the class is primitive and cleared otherwise; 

5.4 Assignment Semantics 

Td assign and retrieve values of a form (or a form 
sequence), ''copy'* srananrirs is used. Assigning a value to a 
form (form fidd or a sequence dement) copies the vahie of 
the form to the assigned location-it does not point to the ^ 
given value. 

Clients that are interested in pointer semantics should use 
forms of the basic type Form Pointer and the function 
Form_set_data__pointer. Forms of type Form Pointer con- 
tain only a pointer to a form; hence, pointer semantics is 65 
used for assignment Note that the C programming language 
supports pointer semantics for array assignment 
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5.5 Referencing a Form Rdd 

A sub-form or field of a constructed form can be accessed 
by its fidd name or by its fidd identifier (the latter is 
generated by the Form padcage). The name of a subfonn 
diat is not a direct descendent of a given form is the path 
name of all the fields that contain the requested subform, 
separated by dot Note that this is similar to the naming 
convention of the C language records. 

A field identifier can be retrieved given the fidd's name, 
and using the fonction F(xm-class_geL^eld^d. The direct 
fields of a form can be traversed by using Form^fiddUdL 
first to get the identifier of the first fidd, and then by 
subsequentiy calling Fonq_fidd_id_next to get the iden- 
tifiers of each of the next fields. 

Accessing a fidd by its name is conveiuent; accessing it 
by its identifier is fast Most .of the Forms package function, 
references a form fidd by the field's identifier aiKi not by the 
field's name. 

5.6 Form-class Definition Language 

Form classes are spedfied using the *f orm-dass definition 
language," which is illustrated bdow. Even complex forms 
can be described within the simple language features 
depicted below. However, the big attraction of a formal 
language is that it provides an extemional framework: by 
adding new language constructs the descriptive power of the 
language can be grcatiy enhanced without rendering previ- 
ous descriptions inconq>atible. 

A specification of a form dass includes the specification 
of some dass attributes, such as the class name, and a list of 
spedfications for each of the dass's fidds. Three exanq)les 
are now illustrated: 



{ 

ihott{ 

IS^JIXED tne; 
IS_JPRIMrnVE true; 
DAXA_SIZE 2; 
DATA^TYPE 9; 
} 

thort-gna y { # A variable size dau of tfaorts. 

IS_FIXED fabe; 
FIELDS { 
{ 

FIELD__CLASS_NAMB abort; 
} 

}} 

enmpk.clBM { 

ISJIXED mie: 

FIELDS { 

fint{ 

FIELD.CLASS-NAMB shoru 

> 

secottd { 

. FIELD_CLASS_NAME sharuamy; 

} 

FIELD_aASS_J^AMB ttriiig_30; 

> 

fourdi { 

FIEU>_CLASS_NAME Integer. 

} 
} 

}> 



To specify a class, the dass's name, a statement of fixed 
or variable size, and a list of fidds must be givea For 
primitive classes the data type and size must also be sped- 
fied. All the other attributes may be left unspedfied, and 
defimlts will be applied. . lb define a dass fidd, dther the 
fidd class name or id must be specify. 
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The fonn-class attributes that can be specified are: 
The class name. 

CLASS^ID— The unique short integer identifier of the 

class. Defaults to a package specified value. 
IS^FIXED — Spedfies whether its a fixed or variable size 5 

class. Expects a boolean value. This is a requiied attribute. 
IS^J^RIMmVE^pecifies whether its a primitive or con- 

str ucted class. Expects a boolean value. Defaults to False. 
FIELDS_NUM— An integer specifying the initial number 

of fields in the form. Defaults to the number of specified 10 

fields. 

DATA^TyPE— An integer, specified by the clients, that 
indicates what is the type of the data. Used mainly in 
defining primidve classes. It does not have de&ult value. 

DATA^SIZE— The size of the forms data portion. Used 15 
mainly in defining primitive classes. It does not have 
default value. .... ^ .^ 

FIELDS — ^Indicates the beginning of the class's fields defi- 
nitions. 

The field attributes that can be specified are: 20 
Tht class field name. 

FIELD CLASS ID— The dass id for the forms to reside in 
the field. Note that the class name can be used for the 
same purpose. 

FIELD_CLASS_NAME---'nie dass nanie for the forms to 25 
reside in the field. 

Here is an example of the definition of three dasses: 
Note that variable length forms contains fields of a single 
dass. •Integer" and "string__30", used in the above 
exaoqsles, are two primitive dasses that are defined within 30 
the Formdass package itself. 

5.7 Form Classes are Forms 

Fonn dasses are in^ememed as forms, lids means 
functions that accept forms as an argument also accept form 
dasses. Some of the more useful fonctions on form dasses 35 
are: 

¥onn_jpack, Fomu_unpadc— Can be used to pack and 

unpack form dasses. 
FornL_copy — Can be used to copy form dasses. 
FQnn_show— Can be used to print form dasses. 40 

5.8 Types 

typedef Formclass 
A form-class handle. 45 

typedef Formdass_id 
A form-class identifier. 



typedef Fonndass_attr 

A form-class attribute type. Supported attributes are: 

FORMCLASS_SIZE— The size of the dass form 
instances. ss 

FORMCLASS^NAMEr-The class name. 

FORMCLASS_ID— A two byte long unique identifier. 

FORMCLASS_FIELDS_NUM— The number of 
(diiect) fields in the dass. This is applicable only for ^ 
fixed length classes. The number of fields in a variable 
length class is different for each instance; hence, is kqpt 
in each form instance. 

FORMCLASS_INSTANCES_NUM— The number of 
form instances of the given dass. ^ 

FORMCLASS_JS_FIXED— Thie if its a fixed lengtii 
form. False if its a variable length form. 



FORMCLASS_IS JRIMTIIVE— True if its a form of 
prinutive type, False if its a constructed form, i.e. Hie 
form has sub fonns. 

FORMCLASS^DATAJTYPB-This fidd value is 
assigned by the user of the forms a to identify the data 
type of primitive forms. In our currmt application we 
use the types constants as defined by the enumerated 
type Form_data_type, in the file forms.h, 

FORMCLASS DATA SIZE--This fidd contains die data 
size, in bytes, of primitive forms. For instance, the data 
size of the primitive dass Short is two. Because it 
contains the C type short, which is kept in two bytes. 

typedef Formdass Jeld_attr 

A form-class fidd attribute type. Supported form class 
fidd attributes are: 

FORMCLASS_FIELD_NAME— nic name of the class 
fidd. 

FORMCLASS_FIELD_CLASS_ID— Hie class id of 
the field's fomL 



typedef Form 



A form handle. 



typedef Form^eldLid 

An identifier for a form's field. It can identifies fields in 
any level of a form. A field identifier can be retrieved form 
a fidd name, using the fonction Form-class_ get, field 
name. A form_field__id is manipulated by the fimctions: 

Form_fidd_JcLfirst and Form^ddUd jext 

typedef Fornu.attr 

A form attribute type. Supported form attributes are: 
FORM_CLASS_JI>— The form's class idcntificn 
FORM_DArA_SIZE— The size of the formes data. 
Available only for constructed, not primitive, forms or 
for primitive forms that are of variable size. For fixed 
length primitive forms this attribute is available via the 
form class. 

FORM^FlELDS_NUM— The number of fields in the 
given form. Available only for constructed, not immi- 
tive forms. For primitive forms this attribute is avail- 
able via the form class. 



typedef Fonn^daia 
50 The type of the data that is kept in primitive forms. 



typedef Fonn_pack;_format 

Describes the possible form paddng types. Supported 
packing formats are: 

FORM_PACIC_LIGHT— Light packing, used mainly 
for inter process communication between processes on 
the same machine. It is more e£5dent then other types 
of packing. Light packing consists of serializing the 
given form, but it does not translates the form data into 
machine independent format. 

FORM_PACK_XDR— Serialize the form while trans- 
lating the data into a machine-independent format The 
machine-independent format used is Sun's XDR. 

5.9 Procedural Interface to the Fdrms-dass Package 

The fonndass package is responsible for creating and 
manipulating forms dasses. The forms package uses these 
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descripuons to create and manipulate instances of given 
form classes. An instance of a form class is called, not 
surprisingly, a fonn. 

Fonnciass_crcatc ^ 

Create a class handle according to the given argument list 
If the attribute CXASS_CFI1£ is specified it should be 
followed by a cfile handle and a path^name. In that case 
formclass_cieate locates the specification for the fonn dass lo 
in the specified configuration file. The specification is com- 
piled into an inteinal data structure for use by the forms 
package. 

Fonnclass^oeate returns a pointer to the dass data 
structure If there are syntax enrors in the dass description is 
file the function sets the error message flag and returns 
NULL 

Formdass^destroy ^ 

The class description specified by the given class handle 
is dismantled and the storage is reclaimed 

If there are live instances of the class then the class is not 
destroyed and the error value is updated to *TORM- 
CLASS_PRR^ONJZEROJNSTANCES_JWM''. 25 

Formdass_get 

Given a handle to a form dass and an attribute of a class 
(e.g. one of the attributes of the type F(Kmdass__attr) ^ 
FGnndass_get returns the value of the attribute. Given an 
unknown attribute die cmx value is updated to '*FORM- 
CLASS_ERR_UNKNOWN.jaTRI.BUTE". 

FQnnclass_getJiandle_by_Jd 

Given a fonns^lass id, FQrmdass_g^_Jiandle_bfy_id 
returns the handle to the appropriate dass descaiptor. If the 
requested dass id is not known F6rm-«lass_get_handle_ 
by_)d returns NULL, but does not set the enor flag. ^ 

Fonndass_geOiandle_by..jiame 

Given a forms-dass name, Formclass_^t_Jiandle_by_ 
name returns the handle to the appropriate class descriptt^. ^5 
If the requested class name is not kiKiwn Forrodass_get^ 
handle_by_name rtturns NULL, but does not set the error 
flag. 

Fbrmdass^gct JdOd ^ 

Given a handle to a form class and a field name this 
function returns the form id, which is used for a fast access 
to the form. If the given fidd name does not exist, it updated 
the enor variable to FORMCLASS_ERR_UNKNOWN_ 55 
FIELD_NAME. 

Formda8S_ficld__get 

Returns the value of the requested field's attribute. If an 60 
illegal id is given this jffocedure, it updated the error variable 
to FORMCLASS_ERIL-UNKNOWN_FIELD JD. 

Foimdass_iserr 

65 

Returns TRUE if Formdass error flag is turned on, 
FALSE otherwise. 
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Formdass_enno 

Returns the formdass enor mmiber. If no eiror, it returns 
FORMCLASS_OK. Rir a list of supported error valuer see 
the file fonndassJi. 

5.10 The Forms Padcage 

Fonn^oreate 

Generate a form (i.e., an instance) of the form class 
specified by the parameter and return a handle to the created 
form. 

Fomu-destiDy 

The specified form is "destroyed" by reclaiming its stor- 
age, 

Fbrm_get 

Given a handle to a form and a valid attribute (e.g. one of 
the values of the enumerated type Fonn^attr) Form_get 
r^ums the value of the requested attribute. 

The attribute F0RM_DArA_SI2E is supported only for 
variable size forms. For fixed size form this information is 
kept in the dass description and is not kept with each form 
instance. 

Requiring the F0RM_J3ATA_SIZE fiom a fixed length 
form will set the error flag to FORM_ERRJJO_^SIZE_ 
ArrR_FOR_FIXED_LENGIH_FORM. 

The attribute FORM_FIELDS_NUM is supported only 
for constructed forms. Requiring the FORM_FIELDS_ 
NUM firom a jaimitive form will set the error flag to 
FORM_ERR_ILLEGAL..^/aTRJOR_PRIMrnVE_ 
FORM. 

If the given attribute is not known the error flag is set to 
FORM_ERR_UNKNO WN_ ATTR. When the error flag is 
set differently, then FORM— OK Fotni^get returns NULL. 

Form_sct_data 

Sets the form's data value to the given value. The given 
data argument is assumed to be a pomter to the data, e.g., a 
pointer to an integer or a pointer to a date structure..However. 
for strings we expect a pointer to a character. 

Note that we use Copy semantics for assignments. . 

FornL-get_daia 

Return a pointer to form's data portion. In case of a form 
of a primitive dass the data is the an actual value of the 
form's type. If the form is not of a primitive class, i.e., it has 
a non zero number of fields, then the form* s value is a handle 
to the form's sequence of fidds. 

Warning, the returned handle points to die fmn's data 
stnicture and should not be altered If the returned value is 
to be modified is shodd be copied to a private memory. 

Form_set_data_pointer 

Given a variable size form. Fortn_5et^data_pointa' 
assigns the given pointer to the points to the forms data 
portion. Form_set__data_j)ointer provide a copy c^oatioii 
with pointer semantics, as opposed to copy semantics. 

If the given form is a fixed length form then the error flag 
is set to FORM-ERR_CANT_ASSIGN^POINTER_ 
TO JIXED_JFORM. 
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Fonn_fieId__set_data 

This is a convenient routine that is equal to caUing 
Fonn^fie]d_^ and then using the retrieved form to call 
Fonn_set__data More precisely: fonn_ field_set_ 
data(fonn, field__id, form_data, size) = fonn_set_ 
data(foTm_field_^et(fQnD, field^id), foim_data« size)» 
phis some error checking. 

Fornx_field_^_daa 

Note that we use Copy semantics for assignments. 

This is a convenient routine that is equal to callimg 
FonxL.field_get and then usipg the retrieved form to caQ 
FoniL-get^data. More precisely: fotm_-ficld_geL_ 
data(fonn, fidd^id, form_data, size) = fornL_fi«:_ 
data(fonn__field_ge^form, field Jd), fonn_data, size) plus 
some error checking. 

Warning, the returned handle pmnts to the fonn's data 
structure and should not be altered. If the returned value is 
to be modified is should be copied to a private memory. 

fbraL_fidd_id__first 

ForaL-field^id^fiist sets the given fieldUd to idoitify 
tbe first direct field of the given form handle. 

Note that the memory for the given field__id should be 
allocated (and fieed) by the clients of the fonns package and 
not by the forms package. 

farm^field_id_next 

Fbrm_field_id_first sets the given field_id to identify 
the next direct field of the given form handle. Calls to 
Fonn_field_id__next must be preceded with a call to 
Form_field_id_first 

Note that the memory for the given field_id should be 
allocated (and freed) by the clients of the forms package and 
not by the forms package. 

Fonn^field_set 

Sets the given form or form sequence as the given form 
field value. Note that we use Copy semantics for assign- 
ments. 

When a nonexistent field id is given then the enor flag is 
set to FORM_ERR JDLLEGAL_ID. 

Form field ^ et 

Return's a handle to the value of the requested field. Hie 
returned value is ddier a handle to a form or to a form 
sequence. 

Warning, the returned handle points to the form's data 
structure and should not be altered. If the returned value is 
to be modified is should be copied to a private memory, 
using the Form^copy filiation. 

When a nonexistenl field id is given, then the enor fiag is 
set to FORM_ERILJUJEGAL_JD and FornL-fiBld_get 
returns NUUL 

Form_field_append 

Fonn__ficld_appcnd appends the given, fCTend_form 
argument to the end of the base_Jbnh form sequence. 
Form_field_.append returns the id of the appended new 
field. 
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Form_field_deleie 

Form_field_delete deletes the given field from the given 
base__forTn. 

5 If a non existing field id is given then the error fiag is set 
to FORM_ERR_JLLBGAL JD and FornL_field_ delete 
reOunsNULL. 

Form__pack 

Form^pack returns a pointer to a byte stream that con- 
tains the packed form, packed according to the requested 
format and type. 

If the required padced type is FORM_PACK_UGHT 
then F6nn.4»ack serializes the form, but the forms data is 
. not translated to a machin&-independeiit representation. 
Ifcnce a lightly packaged form is suitable to transmit 
between processes on the same machine. 
If the required packed type is FORM.PACX^JCDR then 
^ Fonn_pack serializes the form and also translates the form 
representation to a machine-independent representation, 
which is Sun's XDR. Hence form packed by an XDR format 
are suitable for transmitting on a network across madiine 
boundaries. 

2^ Formclass.h. are implemented as forms, hence Form^pack 
can be used to pack form classes as well as forms. 

Fdrm_unpack 

Given an external representation of the form, create a 
30 form instance according to die given dass and unpack the 
external representation into the instance. 

Form classes are in^lemented as forms, hence Fonn^ 
ux^)ack can be used to unpack form classes as well as forms. 

Fonn_copy 

Copy the values of the source form into the destination 
form. If the forms are of different dasses no copying is 
performed and the error value is updated to FORM_ERR_ 
40 ILLEGAL_CLASS. 

Formclasses are implemented as forms, hence Form, 
copy can be used to copy form dasses as well as forms. 

Form_show 

45 

Retum an ASCII string containing the list of fidd names 
and associated values for indicated fields. The string is 
suitable for displaying on a tominal or printing (e.g., it will 
contain new-line characters). The returned string is allocated 
50 by the function and need to be freed by the user. (Hiis is 
fbnction is very usefiil in debugging.) 

Formclasses are implemented as forms, hence Form, 
show.can be used to print form dasses as well as forms. 

55 Form_iserT 

Returns TRUE if the error flag is set, FALSE otherwise. 

Fomi_ermo 

* ReUims the formclass error number. If no error, it returns 
FORMCLASS^OK. Hie possible error values are defined 
in the file fonns.h. * 

GLOSSARY 

65 

There follows a list of definitions of some of the words 
and phrases used to describe the invention. 



04/19/2004, EAST Version: 1.4.1 



5,557, 
73 

Access Procedure: a broader tenn than service discipline or 
service protocol because it encompasses more than a 
communications protocol to access data from a particular 
server, service, plication. It includes any procedure by 
which the information requested on a particular subject 5 
may be accessed. For example, if the subject request is 
*Tlease give me the time of dale", the access procedure to 
which this request is mapped on the service layer could be 
a call to the opiating system on the conqniter of the user 
that initiated the request An access proc«hire could also ^ 
involve a call to a utility Ingram. 

Application: A software pr ogr am that runs on a computer 
other than the operating system programs. 

Architectural Decoiq)ling: A property of a system using the 
teachings of the inventioa This property is inherently 
provided by the function of the information layer in 
performing subject-based addressing services in mapping 
subjects to services and service disciplines through which 
information on these subjects may be obtained. Subject- 
based addressing eliminates the need for the data con- 
suming processes to know the network architecture and 20 
where on the network data on a paiticul ar subject may be 
found. 

Attribute of a Form Class: A property of form class such as 
whether the class is primidve or constructed Size is 
another attribute. 25 

Class: A definition of a gimip of forms wherein all forms in 
the class have the same format and the same semantics. 

dass/Qass Descriptoi/Class Definition: A definition of the 
structure and organization of a particular group of data 
records or ^forms'* all of which lave the same internal 30 
representation, the same organization and the same 
semantic infonnatioiL A dass descriptor is a data record 
or "^object" in memory that stores the data which defines 
all these parameters of the dass definitiQiL The Class is 
the name of the group of forms and the Qass Definition 35 
is the infbimatian about the group's common chaiacter- 
istics. Classes can be elth^ primitive or constructed. A 
primitive dass contains a dass "gnw that uniqudy iden- 
tifies the dass (this name has assodated with it a. dass 
number or dass_id) and a spedficatxon of the represeo- 40 
tation of a single data value. Hie specification of the 
representation uses wdl known primitives tiiat the host 
computer and dient applicatioiK understand such as 
strir^20 ASCn. flo^Gig point, integer, string^O 
EBCDIC etc. A constructed dass definition includes a 45 
unique name and defines by name and content multiple 
fidds that are found in this kind of form. The dass 
definition specifies the organization and semantics or the 
form by specifying field names. The field names give 
meaning to the fields. Each field is spedfied by giving a 50 
fidd name and the foaa class of its data since each fidd 
is itself a form. A field can be a list of forms of the same 
dass instead of a single form. A constructed class defi- 
nition contains no actual data although a dass descriptor 
does in the form of data that defines the onganization and 55 
semantics of this kind of form. All actual data that define 
instances of forms is stored in forms of primitive dasses 
and the type of data stored in primitive classes is spedfied 
in the dass definition of the primitive class. For example, 
the primitive dass named "Age" has one field of type 60 
integer_3 which is defined in the dass definition for ibc 
age class of forms. Instances of forms of tins dass contain 
3 digit integer values. 

Qass Data Structure: All the data stored in a class manager 
regarding a particular dass. The class descriptor is the 65 
most in;qK)rtant part of this data stnicture, but Uiere may 
be mote information also. 
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Qass Definition: The specification of a form dass. 

Qass Descriptor A memory object which stores die form- 
class definition. In the dass manager, it is stored as a 
form. On disk, it is stored as an ASCII siring. Basically, 
it is a particular representation or format for a dass 
definitioiu It can be an ASCII file or a form type of 
representation. When the class manager does not have a 
class descriptor it needs, it asks the fordgn ^iplication 
that created die dass definition for the dass descriptor. It 
then recdves a dass descriptor in the fcmnat of a fbnn as 
generated by die fordgn application. Alternativdy, tiie 
dass manager searohes a file or files identified to it by tiie 
application requesting die semantic-dependent operation 
or identified in records mainrained by the class manager. 
Hie dass definitions stored in these files are in ASCII text 
format The dass manager then converts die ASCII text so 
foimd to a dass descriptor in the format of a native form 
by parsing the ASCn text into the various field names and 
specifications for the contents of each fidd. 

Client Application: a data consuming or data publishing 
process, i.e., a computer program which is nmning. other 
than an operating system program that is linked to the 
communication interface according to the teachings of the 
invention. 

Computer NetWcnk: A data pathway between multiple com- 
puters by hardware connection such as a local or wide 
area networic or between multiple processes nmning on 
the same computer d!m>ugh facilities provided by die 
operating system or other software programs and/or 
shared memory induding a Unix pipe between processes. 

Configuration Decoupling: The property of a computer 
system/networic in^ementing the teachings of the inven- 
tion which is inherendy provided by the distributed com- 
munication layer. This layer; by encE^Kulating the detailed 
protocols of how to set up and destroy communication 
links on a particular configuration for a computer net- 
work, fitees client processes,, whether data puUisbers or 
data consumers from the need to know these details. 

Configuration File: A file that stores data that (tescribes the 
properties and attributes or parameteiB of the various 
software components, records and forms in use. 

Constructed Hdd: A fidd whidi contains another form or 
data recaid. 

Consumer a dient or consumer plication or end user 
which is requesting data. 

Data Distribution Decoupling: The fimction of the commu- 
nication interface software according to the teachings of 
the invention which frees client plications of the neces- 
sity to know and provide the network addresses for 
servers providing desired services. 

Decoupling: Freeing a process, software module ar appli- 
cation from the need to know the communication proto> 
cols, data formats and locations of all other process^, 
con^uters and networks wiUi which data is to be inter- 
changed 

Distributed Communication Layer the portion of the appa- 
ratus and method according to the teachings of the inven- 
tion which maps the access procedure identified by the 
service layer to a particular network or transparent layer 
protocol engine and sets up the required oonmiunication 
channel to die identified service using the selected net- 
work protocol engine. 

Field: One component in an instance of a form which may 
have one or moro components each named differentiy and 
each meaning a different thing. Fidds are '"primitive" if 
they contain actual data and are "constructed" if .tiiey 
contain other forms, i.e., groupings of other fidds. A data 
record or form which has at least one fidd which contains 
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another form is said to be "nested". The second form 
recorded in the constnicted field of a fint form has its own 
fields which may also be primitive or constructed Thus, 
infinitely complex layers of nesting may occur. 

Foreign: A computer or software process which uses a 
different format of data record thm the fonnat data recoid 
of another computer or software process. 

Fonn: A data reand or data object which is sdf-describiQg 
in its structure by virtue of inclusion of fields containing 
class descriptor numbers which correspond to class 
descriptors, or class definitions. These class descriptors 
describe a dass of form the instances of which an have the 
same internal rqiresentation, the same organization and 
the same semantic information. This means that all 
instances, i.e., occurrences, of forms of this class have the 
same number of fields of the same name and the data in 
cprre^nding fields have the same representation and 
each corresponding field means the same thing. Forms 
can be either primitive or constructed. A form is primitive 
if it stares only a single unit of data. A form is constructed 
if it has multiple internal components called fields. Each 
field is itself a form which may be either primitive or 
constructed. Each field may store data or the dass^id, 
i.c., die class number, of another form. 

Format Operation: An operation to convert a form ficom one 
format to another fcmnat 

Format or IVpe: The data representation and data organiza- 
tion of a strucniral data record, i.e., form. 

Handle: A pointer to an object, record, file, class descriptor, 
form etc. Hiis pointer essentially defines an access path to 
the object Absolute, relative and offset addresses are 
examples of handles. 

ID: A unique identifier for a fonn, record, dass, memory 
object etc. The dass numbers assigned the dasses in this 
patent specification are examples of ID's. 

Infbnnadon Layer: the portions of die apparatus and method 
according to the teachings of the invention whidi per- 
forms subject based addressing by moping information 
requests on particular subjects to the names of sendees 
that supply information on the requested subject and tiic 
service disdplines used to communicate witii these ser- 
vices. 

Interface: A library of software programs or modules which 
can be invoked by an application or another module of the 
interface which provide support functions for carrying out 45 
some task. In the case of the invention at hand, the 
cormnunication interface provides a library of pr ograms 
which implement the desired decoupling between foreign 
processes and computers to allow simplified program- 
ming of applications for exchanging data with foreign 
processes and computers. 

Interface Card: Hie electronic circuit that makes a physical 
coimection to the networic at a node and is driven by 
transparent layer protocol programs in the operating sys- 
tem and netwoiic and data-link protocol programs on the 55 
interface card to send and reodve data on the netwt)rk. 

Native Forxnat/Form: The format of a form or the form 
structure native to an application and its host computer. 

Nested: A data structure comprised of data records having 
multiple fidds each of which may contain other data 60 
records tiiemsdves containing multiple fields. 

Network Protocol Engine: a software and hardware combi- 
nation that provides a facility whereby conununication 
may be performed over a network using a particular 
protocol. 

Node: Any computer, server or terminal coupled to tiie 
counter network. 
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Primitive Reld: A field of a form or data record which stores 
actual data. 

Process: An instance of a software program or module in 
execution on a computer. 

Semantic-Dependent Op^^on: An operation requiring 
access to at least the semantic information of the class 
definition for a particular form to supply data from that 
form to some requesting process. 

Semantic Information: ^th respect to forms, the names and 
meanings of the various fields in a form. 

Server A computer running a data producer process to do 
something such as supply files stored in bulk storage or 
raw data from an information source such as Tblerate to 
a requesting process even if the process is rurming on the 
same computer which is nmning the data producer pro- 
cess. 

Servo- Process: An application process that supplies the 
functions of data spedfied by a particular service, such as 
Tderate, Dow Jones News Service, etc. 

Service: A meaningful set of functions or data usually in the 
form of a process running on a server which can be 
exported for use by client applications. In other words, a 
service is a general class of applications which do a 
particular thing, e.g., plications supplying Dow Jones 
News informatioa Quotron datafeed or a trade ticket 
router. An application will typicdly export only one 
service, although it can export many different services. 

Service Disdpline or Service Protocol: A program or soft- 
ware module implementing a communication protocol for 
communication with a particular service and mcluding 
routines by which to sdect one of several servers that 
suppUes a service in addition to protocols for communi- 
cating with the service and advising the communication 
layer whidi server was selected md requesting that a 
communication link be set up. 

Service Access Protocol: A subset of the assodated service 
disdpline that encapsulates a conununication protocol for 
communicating with a service. 

Service Instance: A process rurming on a particular coix^mter 
and which is capable of providing the spedfied service 
(also sometimes called a server process). For a given 
service, several service instances may be concurrentiy 
providing the service so as to improve performance or to 
provide fault tolerance. The distributed commnnication 
component of the TIB''^ conmumication software iinpl&- 
ments "fault-tdcfanf coitmmnication by providing auto- 
matic switchover firom a failed service inatanpg to an 
operational one providing the same service. 

Service Layer the portion of apparams and metiiod accord- 
ing to the teachings of the invention that maps data 
received ftum tte information layer to the access proce- 
dure to be used to access the service or other source for 
the requested information to provide service decoupling. 

Service Decoupling: The function of the service layer of the 
communication mterfttce software according to die teach- 
ings of the invention which frees dient implications of die 
necessity to know and be able to implement die particular 
communication protocols necessary to access data from or 
otiierwise communicate with services which supply data 
on a particular subject 

Service Record: A record containing fidds describing die 
important characteristics of an application providing die 
spedfied service. 

Subject Domain: A set of subject categories (see also subject 
space). 

Subject Space: A hierarchical set of subject categories. 

Subscribe Request A request for data regarding a particular 
subject which does not spedfy the source server or 
servers, process or processes or the location of same from 
which the data regarding this subject may be obtained. 
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Tianspoit Layer A layer of the standard ISO model for 
netwoiks between computers to which the communicar 
tion interface of the invention is linked. 

lYanspon Protocol: The particular communication protocol 
or discipline implemented on a particular network or 
group of netwodcs coupled by gateways or other inter- 
network routing. 

Appendix A 

Appendix A, which can be found in the application file, is 
the complete run time collection of C language source code 
programs that embody the invention. This code runs in the 
Sun Microsystems OS 4.1 environment on Sun 4 machine.^ 
such as SPARC 1 and the SPARC 370 and 470 servers. 

TIB Build 
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TIB may be built on Sun Unix woikstations runmog Sun 
OS 4.1. The C compiler distributed by Sun is used for 
conqnlation. Also required are the X11R3 (or X11R4) 
libraries. TIB was built using the "gmake" utility (distrib- 
uted by the Free Software Foundation in Cambridge, Mass.) 
Each directory which must be built contains gmake file 
named GNUmakeffie. lb boild the API, three invocadons of 
gmake should be pe tfo n ned on eadi diiectoiy contMnixig a 
GNUmakefile. The first pass directs gmake to build Include 
files" by numing *gmake EXPORT-INCS". The second pass 
directs gmake to build the TIB. libnnies by running 'gnoake 
EXPORT-LIBS'. The last pass through the directories 
directs gmake to build the TIB API libraries by cunning 
*gmake EXPORT-BINS'. 

Several gmake suppoit files exist, and a dnectory should 
be created to hold these files. The environment variable, 
SMINCLUDE, should be set to reference this directoiy 
before performing the build. 

What is claimed is: 

1. In a distrilmted computing environment including one 
or more computers coupled together by one or more net- 
works, said one or more computers having in execution 
thereon one or more subscriber plications each of which 
has the c^ability of making a subscription request request- 
ing that data on one or more subjects be sent to said 
subscriber application whenever data on said subject 
becomes avaflable until said subscription is canceled, and 
said (me or more conq)uters having in execution thereon one 
or more service applications, each of wMdi is capable of 
transmitting over said one or more networks data on one or 
more subjects, an apparatus comprising: 
intermediary software controlling said one or more com- 
puters and coupled to said one or more networks and 
said one or more subscnber and service plications, so 
as to logically decouple said one or more subscriber 
applications from said service plications in the sense 
of performing all necessary functions to get data 
requested by subject by said subscriber applications 
from one or more service q)plications that supply data 
on the requested subject to all computers on which a 
subscriber application is in execution which has an 
open subscription to the subject of said data and from 
each such computer to the subscribing applications 
themselves and delivering said data only to said com- 
puters on which there is in execution a subscriber 
application haying an open subscription to the subject 
of said data, said logical decoupling also implemented 65 
by said intermediary software by eliminating the need 
to have computer code in any said service plication 
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which ou^ts any data, other than the subject itsdf, 
which controls where in said distributed computing 
environment data published by said service plication . 
in execution on one or more of said computers is 
distributed or which identifies or locates any subscriber 
application or computer in said distributed computing 
environment to which data published by any said 
service application is to be distributed, and by elimi- 
nating the need for any subscriber application to 
irsckde computer code which identifies any particular 
service plication from which data is to be sought or 
which can find a service ai^lication which can supply 
data on a subject desired by said subscriber ^plication, 
said intermediary software for controlling said one or 
more computers so as to automatically set up a com- 
munication path through said network between service 
applications which publish data on a subject and all and 
' only computers having in execution thereon subscriber 
qiplications having an open subscription to the subject 
of said data. 

2. An paratus for use in a distributed computing system 
comprised of one or more computers some of which m^ be 
clients and some of which may be seivera and some of wMdi 
nuQT be both clients and servcn, all said computers coupled 
by a network or data path, said paratus for intecfiscing ai 
least one plication process in execution on at least one 
client computer having an operating system emboc^g a 
transport layer comnnmication protocol and a network inter- 
face circuit card couplii^ the client oonpter to said net- 
work to which is coupled at least one server compter 
having an operatii^ system embodying a transport layer 
protocol and execution of which is controlled by at least one 
service process, such that said at least one plication 
process requesting data on a subject can be selectively 
linked to at least one service process which is capable of 
supplying data on said subject using a subscription para- 
digm, and wherein each said at least one plication process 
is enable of issuing subscription requests requesting an 
ongoing flow of data on the subject named in each said 
subscription request whenever said data is published, com- 
prising: 

c ommunic a tio n means including at least one protocol 
engine for execution on each of said host and server 
conqiuters and coupled to said transport layer conunu- 
nication protocols of said host and server computers, 
each protocol ec^gine encapstdating a commumcation 
protocol providing reliability or efficiency gnhnncing 
functions not siq)plied by said transpod layer commu- . 
nication protocol, said protocol engines for exchanging 
data with each other over said networic, said commu- 
nkation means for receiving a link request to set up a 
subscription-based data communication link to a 
selected server computer and for selecting and invoking 
selected ones of said protocol engines encapsulating a 
desired communication protocol and for invoking said 
transport layer communicadon protocol to physically 
establish said data communication link; 

service means for processing subscription requests, said . 
service means including at least two service disci- 
pline(s) including a consumer side service discipline 
program for controlling one or more of said computers 
so as to communicate with said at least one application 
process and a publisher side service discipline progi am 
for controlling one or more of said computers so as to 
communicate with said at least one service process and 
which is capable of receiving data published on a 
subject by said service process and distributing said 
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published data to only those conqmters having in 
execution thereon an application process having an 
open subscription to the subject of said data, said data 
published by said service process containing no data 
indicating where said data is to be sent within said 
distributed computing system, other than the subject of 
the published data itself, said service means for trans- 
mitting said data to aU application processes which 
have issued subscription requests naxning the subject of 
said data as being of inteiest, and wherein at least said 
consumer side service discipline encapsulates a com- 
munication protocol for communicating to at least a 
selected one of said services via the publisher side 
service discipline coupled thereto, said service means 
for receiving a subscription link request requesting 
estabfishment of a subscription communication link 
with one or more of said service processes named in 
said subsioription communication Ihik which publishes 
data on a particular subject and for generating and 
transmitting to said communication means said link 
request requesting the establishment by said commu- 
nication means of said subsciiption-based data com- 
municadon link with the service identified in said 
subscription link request, and for sending a subscrip-. 
tion registration message to said publisher side service 
discipline coupled to said one or more service pro- 
cesses requesting that all data on said subject, when- 
ever published, be sent to each said application pro- 
cess(es) which bas issued a subscription request on the 
subject so long as said subscription has not been 
canceled, said publisher side service discipline being 
selectively coupled to said service process for register- 
ing said subscription in a subscription list identifying at 
least all application processes that have active subscrip- 
tions and the subjects tiiereof, at least one of said 
service disciplines being coupled to each said ^iplica- 
tion and services process for which an active subscrip- 
tion and communication Imk have been estabHsbed and 
cooperatix^ with each said application process that 
issued a subscription request and at least one said 40 
service process that is capable of supplying data on the 
subject so as to forward data published by said service 
pnx:ess(es)on the subject of an active subscxqMion to all 
said application processes having an active subscrip- 
tion on said subject, said service means for filtering said 
published data by subject on the service side of the data 
communication link such that data published by said 
service process which does not correspond to the 
subject of any active subscription is not transmitted 
over the network but sudi Uiat data having a subject 
matdung the subject of an active subscriptim reaches 
all application processes wUdi have active subscrip- 
tions on die subjea; and 
information means for controlling one or more computers 
so as to present a programmatic interface at least to said 55 
one or more application processes and said at least one 
service processes such said one or more iqpplication 
processes can open a subscription to a subject simply 
by pasang a subscribe requiest to said programmatic 
interface and passing a subject tiiereto in said subscrip- 60 
tion request and such that a service process can publish 
data on a subject to all said application processes 
having an open subscription to said subjea simply by 
invoking a publish function of said programmatic inter- 
face and passing the data to be published thereto along 
with a subject of said data, said information means for 
receiving said subscribe request(s) from said one or 
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more application processCes), each said subscribe 
request containing at least a subject and the identity of 
a callback routine for said plication process, and, for 
each said subscribe request, mapping said subject con- 
tained therein to one or more of said service processes 
which can supply data on said subject and at least a 
selected one of said service disciplmes which encap- 
sulates a conununication protocol capable of commu- 
nicating witii said selected service or services, and for 
transmitting the subject of said subscribe request to said 
service means along witii data identifying and/or giving 
the address ni said distributied computing system of at 
least one service process with whidi subscription based 
data communication links are to be established. 

3. The apparatus of claim 2 wherein data transmitted 
between said application process and said service process is 
transmitted over said data path or netwoik as a data message 
comprising a plurality of sequential packets, each of - which 
has a header and error corrections bits as part of said packet* 
and wherein said communication means further comprises: 

a memory; 

means for adding reliability enhancing sequence numbers 
to said packet headers prior to transmission; 

means for transmitting over said data path or network the 
packets, error correction bits and sequence numbers 
which comprise a complete data n»ssage; 

means for saving said packets in said memory with said 
sequence numbers and error correction bits in case 
some or all of the packets need to be retransnoitted; 

means for transmitting said packets; 

means for recdving said packets and checking said reli- 
abiUty sequence numb^ to detemune that all packets 
have arrived and using said error correction bits to 
deternune if any of said packets were garbled during 
transmission, and for requesting retransmission of any 
missing or ^rbled packets, or acknowledging that all 
packets were properly received; and 

means for retransmitting any missing or garbled packets 
and for flushing any packets no longer needed from 
said mcmoiy. 

4. In a distributed computing environment including at 
least one data consuming process in execution on one or 
more computers and at least one data producing process in 
execution on one or more computers, said one or more 
computers and said data consuming and data producing 
processes coupled by at least one data path and/or network, 
an apparatus comprising: 

one or more con^uters in . said distributed computing 
enviroimient processing of which is controlled by one 
or more subject based addressing programs, said one or 
more subject based addressing programs for controlling 
said one or more computers to receive a subscription 
request from one or more data consuming processes to 
locate and access data on a specified subject, and for 
controlling said one or more computers to automati- 
cally locate at least one data producing process which 
produces data on said subject and for controlling said 
one or more computers to automatically generate each 
of said one or more link requests requesting that one or 
more subscription conununication links be established 
over said data path between at least one of said data 
produdng pnxxsscs which supply data on the subject 
of said subscription request and at least one of said data 
consuming processes which made subscription requests 
for data on said subject; and 

one or more computers m said distributed computing 
enviiomitent controlled by one or more communication 
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programs to receive said link requests from said one or 
more computers controlled by said subject based 
addressing programs, and for controlling said one or 
more computers so as to automatically establish said 
one or more subscription communication links over 
said data path, each of said one or more subscription 
communication links being established using a com- 
munication protocol qipiopriate for communication 
with the data producing piocess with which said sub- 
scription communication link is established, said one or 
more subscription communication links being estab- 
lished by controlling said one or more conqiuters 
controlled by said one or more communication pro- 
grams 8udi that titers is no need for said one or more 
computers controlled by said one or more communi- 
cation programs to receive any address or address 
related data, other than the subject itself of the sub- 
scription request, fiom any data consuming^process 
Indicating where in said distributed computing envi- 
ronment a data producing process which is publishing 
data on the subjea may be found and by controlling 
said one or more conpiters controlled by said one or 
more commimication programs such that thm is no 
need to receive any data &om any data producing 
process, other than the subject itself of die data pub- 
lished by said data producing process, indicating or 
controlling where the data published by the data pro- 
ducing process is to be sent in said distributed com- 
puting environment, said one or more communication 
programs also for controlling said one or more com- 
puters so as to automatically transport data published 
on the subjects of any active subscription(s) to all but 
only said one or more computers processing of which 
is controlled by a data consuming processes which 
issued a subscription request requesting data on said 35 
subjea and for controlling said one or more c(Hxq)uter8 
so as to automatically route said data published on a 
subject for which there is an active subscription to all 
said one or more data consuming processes having an 
active subscription on the subject of said data until said 40 
subscription(s) is canoRleri. 

5. The apparatus of daim 4 whernn said subject based 
addressing program indudes directoiy services means for 
storing data identifying which data producing processes 
supply data on which sutgects and for searohing said data in 
response to receipt of a subscription request and returning 
any data located during said search identifying or giving the 
address in said di^ributed computing envirorunent of one or 
more data producing processes which can supply data on the 
subject of said subscription request to said one or more 
computers controlled by said one or more subject based 
addressing programs for tise in generating said one or more 
link requests. 

6. The q)paratus of claim 4 wherein each said subject can 
have multiple parts which are arranged into a subject space 
containing 30 or more multiple part subjects, and wherein 
said subject space is arranged hierarchically based upon said 
multiple parts of said subjects, and wherein said one or more 
computers controlled by said one or more subject based 
addressing programs include means for locating all data 60 
producing processes which publish data having a subject 
which satisfies all parts of said multiple part subject 

7. The apparatus of daim 4 wherein said subject con- 
tained witMn said subscription request can have multiple 
pads, and wherein each said multiple part subject can 
include empty strings or other wild caiil notations, and 
wherein said one or more computers controlled by said one 
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or more subject based addressing programs inchides means 
for locating all data producing processes which supply data 
having a subject which satisfies all parts of said multiple part 
subject which are not empty strings or wild card notations, 
and wherein no data producing process coiUrolling any of 
said one or more computers so as to publish data on one or 
more subjects includes any software routine, program or' 
data the content of whidt is dependent upon die existence or 
location in said distributed computing envinminent of any 
data consuming process which can issue subscription 
request or the purpose of which is to ditectiy or indirectly 
locate any data oonsumix^ process which can issue sub- 
scription request, and wherein no data producing process 
controlling any of said one or more con^mters so as to 
publish data on one or more subjects indudes any software 
routme, program or subroutine which functions to assist in 
any way, other th^ outputting tiie.subject of published data, 
in routing data between any said data producing process 
which controls said one or more conq)utcrs so as to publish 
data and any data consuming process controlling one or 
more computers, and wherein no data consuming process 
controlling one or more computers includes any software 
routine, program or the content of which is dependent upon 
the existence or location of any data producing process or 
the purpose of which is to control one or more of said 
computers so as to locate any data producing process other 
than by outputting the subject itself of the subsoiptian 
request 

8. The ^parauis of daim 6 wheiem said multiple parts of 
said subjea are hierarchically arranged, and wherein there 
are at least 30 data producing and data consuming processes 
controUing processing by one or more of said computers in 
said distributed computing environment. 

9. The apparatus of claim 7 wherein said multiple pads of 
said subjea are hierarchically arranged. 

10. The apparatus of daim 5 wherein said one or more 
communication programs indnde means coupled to each of 
said one or more oon^tecs under control of one or more of 
said data piodudng processes for keeling a subscription list 
of all of said one or more data consuming processes vMdti • 
have requested subscriptions and the subjeos of said sub- 
scriptions and for filtoing data published by said one or 
more computers under control of said one or more data 
publishii^ processes such that only data having a subjea 
which matches the subject of an active subscription is., 
transmitted over said network or data patL 

11. The ^Tparatus of claim 6 wherdn each said computer 
under control of one of said conummication |Ht)grams 
further con^mse means coupled to each data consumirig 
process and each data producing process via the one or moic. 
computers controlled thereby for ke^nng a list indicating for 
each subject whetiier tiiere are or arc not active subscriptions 
for that subject, and wherein each said computer under 
control of one of said communication programs fiirthCT 
comprises means for checking said list each time a data 
message on any subjea is published by one or more com- 
puters under control of one or more of said data producing 
processes and for broadcasting over said data patii or na- 
work each data message published by one or more comput- 
ers under control of any data produdng process on a subjea 
for which there is at least one active subscription indicated 
on said list, and each said computer under continol of at least 
one of said communication programs further coniprisiQg.a 
communication daemon means for controlUng execution by 
eadi said computer by multitasking so as to cause eadi said . 
computer under control of at least one of said conmiunica- 
tions means to filter incoming data messages by subjea so 
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that data messages on any subject for which there is an 
active subscriptioQ entered by a data consuming process 
controlling processing in a multitasking environment on one 
of said conpiters on which a communication daemon 
means is also controlling execution of said computer on a 
multitasking basis are automatically sent to all data cosi- 
suming processes in execution on said computer that 
requested said data and all other data messages on subjects 
for which there are no active subscriptions by any data 
consuming process controlling execution of said computer 
on a multitasking basis are discarded. 

IZ Hie apparams of claim 8 wherein said one or more 
computers under control of said one or more communication 
programs further comprises means coupled to each data 
consoming process for filtering incoming data by subject so 
that only data on the requested subject reaches the data 
consuming process which requested said data. 
- 13. Hie apparatus of claim 4 fuitber comprising a dis- 
tributed communications component oonqnised of one or 
more computers controlled by one or more computer pro- ^ 
grams to receive instructions tarn said one or more com- 
puters controlled by one or more subject based addressing 
programs to establish communicatioiis with one or more 
oompaters controlled by one or miKe data publishing com- 
puter programs, said distributed communications compo- 
nent for shiel^ung said plication and data publishing 
computer programs torn the need to have routines or 
compater instrucdons therein to control said one or more 
computers so as to be able to know the i^iysical distribution 
of other computers and computer programs in said distrib- 
uted system and the communication processes so as to be 
able to communicate with said other computers and com- 
puter programs thereby insulating said ^plication and data 
publi^iing computer programs from having dependencies 
on various characteristics of said distributed system 
designed into the computer programming instructions of 
said application and data publi^iing computer programs 
which could render said application and data publ^hing 
computer programs obsolete when said characteristics of 
said distributed system change. 

14. In a computing environment having one or more 
computers coupled by one or marc data paths and/or one or 
more networks, and having one or more data producing 
processes which publish data messages on one or more 
subjects arranged into a subject space, and one or more data 
consuming processes which need data on one or more 
subjects, said one or more data produdiig processes and said 
one or more data consuming processes in execution on said 
one or more computers, a process comprising the steps of: 
storii^ data encoding the sutrjects in said subject space in 
a memory or other means for storing data coupled to of 
one or more of said computers, and storing in said 
memory or said other means for storing data moping 
data which maps the identity and/or the address in said 
computing environment of one or more of said data 
producing processes for execution on one or more of 
said computers in said distributed computing system 
which can supply data on a subject for one or more 
subjects in said subject space; 
receiving a subscription request &om one or more data 
consuming processes for data on a particular subject 
and automatically locating all data producing processes 
which can supply data messages on that subject by 
using the subject of said subscription request to search 
said mapping data to locate a data produdng process 
which can supply data on that subject without any 
assistance from said one or more data consuming 



25 



30 



35 



40 



45 



50 



55 



60 



65 



processes other than receipt of the subject of the 
subscription request, and generating a link request, said 
link request directly or indirectly identifying said at 
least one data producing process located by search of ' 
said mapping data which can supply data on the 
requested subject included in said subscription request, 
said link request requesting that a communication link 
be established between at least one of said data pro- 
ducing processes identified in said link request and all 
of said data consuming processes wfaicfa requested data 
on said subject; and 

receiving said link request and automatically setting up a 
. communications link with said' at least one data pro- 
ducing process identified direcdy or indirectly in said 
link request, and directing data messages received from 
any said data produciQg process on said subject to all 
and only computers having their processing controlled 
by said data consummg processes' which requested data 
on said subject without receiving any data from any 
said data producing process which publishes a data 
message, other than this subject of the data itself^ which 
indicates or controls to whidi computers in said comr 
puting environment any said data message is to be sent, 

and wherein no data producing process needs to include 
any data or con^uter instructions the purpose of which 
is to identify or locate any said data consuming process 
other than to output the subject of the data message 
being published. 

15. The process of claim 14 wherein said sXep of auto- 
matically setting up said communications link further com- 
prises the step of sending a request for a subscription to said 
at least one data producing process identified in said link 
request, said subscription request identiiying directly or 
indirectly the data consuming process or processes which 
requested data on said subject, and wherein said step of 
directing data messages published by said data producing 
process on each said subjectindudes the step of directing all 
data messages published by said at least one data producing 
process to all data consundng processes which have an 
active subscription for data on said subject, said directmg of 
data messages on a subject to all data consuming processes 
having active subscriptions for data on said subject occur- 
ring continuously eadk time a data message on said subject 
is published but not transmitting any message on any subjea 
to any conqmtcr in said communication environment not 
having io execution thereon a data consimiing process 
having an active subscription to the subject of said message, 
but ceasing to direct data messages to any data consuming 
process which has canceled its subscriptioiL 

16. The process of claim 14 wherein the step of locating 
all data producing processes which can supply data mes- 
sages on the subject of a subscription request includes the 
steps of passing the subject of said subscription request to 
said one or more computers controlled by said directoiy 
services program which causes said one or more computers 
controlled by said directory services program to search said 
mapping data in said data stored in said computer memory 
encoding said subject space to locate the subject of said 
subscription request and return data identifying and/or giv- 
ing the address in said computing environment of at least 
one data producing process which can supply data on the 
. subject if any such process exists, and wherein said data 
returned by said computer controlled by said directory 
services programs is used to generate said link request, and 
wherein the step of automatically setting up a communica- 
tions link further comprises the step of making one or more 
subscription lists listing subjects for ^ch there are active 
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subscriptions, said one or more sobscription lists directly or 
indiieclly identifying the data consuming piocesses that 
initiated the active siibsciiptioaB, and wherein the step of 
directing data messages on a subject to all data consuxniqg 
processes which requested data on said subject finttier 5 
comprises the steps of comparing the subject of each data 
inessage published by any data publishing process to the 
subjects having active subscripdons listed on said one or 
more subscription lists and directing any dam message 
published on a subject for which thm is an active subscrip- 
tion to aU data consuming processes that requested data on 
the subject of said data message, but not allowing any dflta 
message publishisd by said data producing processes which 
does not match the subject of at least one active subscription 
to be transmitted over said data patiL 

17. The process of claim 14 wherein data messages 
transmitted between said data prodndi^ processes and said 
data oonsunnng processes, hereafter referred to as processes, 
are transmitted as'sdf descrihinjg'data objects, wherein each 
self describing data object is comprised of one or more fields 
each of which is either a primitive class form which stores 20 
data or a constructed class form wMch is comprised of otiier 
tidds which themselves may be primitive or constracted 
class forms, each said constracted dass form bdonging to a 
class which has a conespon^ng dass definition, said sdf 
describing data objects being organized into dasses defined 25 
by class definitions, each daiss definition conqxtiung a list of 
the fields by name and data rgnesentation type which are 
common to all sdf describing data objects of tiiat d ass, each 
self desQdbir^ data otgect induding both data farmat infor- 
mation and actual data or fidd values for eadi said field, and ^ 
further comprising the steps of: 

automatically converting any self describing data objects 
to be transmitted fiom one process to another from the 
format of the transmitting process to the format nec- 
essary for transmission across said data path prior to 35 
transmissian thereof, and then transmitting said self 
describing data object through said data path; and 

automatically converting any self describing data objects 
received after transmission through said data path 
which are bound for either a data consuming process or 40 
a data produdng process, from the format used to 
transmit data across said data path to the format used tiy 
said recdving process. 

18. The process ck daim 17 wherein each said conversion 
^ comprises the steps of: 45 

recdving a format conversion call identifying the desired 
"from** format and the desired **to*' format and identi- 
fying a specific self describing data object upon which 
the conversion is to be performed; 

accessing a table storing identifiers of particular fiom-to ^ 

format conversions; 
locating the first field in said self describing data object 

which is a primitive dass form; 

using the format information stared in said self describing 55 
data object for the primitive field so located, looking up 
a "firom** format in said table conesponding to the 
format of the primitive dass field so located and 
determining the required *^o** format for the conversion 
spedfied in said conversion call; ^ 

using a table storing pointers to appropriate conversion 
software routines for the desired from-to format can- 
version, looking up a &om-to format conversion 
pointer using the *^m" and formats just deter- 
mined and using said pointer to execute an appropriate 65 
software routine to perform the desired from-io format 
conversion; 



86 

locating the next fidd containing a primitive class fonn in 
the self describing data object identified in said con- 
version call and repeating the above steps to convert the 
data in the next primitive class form from the then 
existing *^m" format to die desired "to** format and 
repeating this process until all fidds containing prinu- 
tive class forms have been so processed; and 
processing every fidd containing a constructed class form 
as defined above by searching the constructed dass 
form until the first field is found containing a primitive 
class form and converting the format thereof using the 
steps defined above and r^)eating tiiis process until all 
fidds containing primitive class forms for all levels of 
nestmg of fidds containing constructed dass forms 
have been converted to tire desired *to'* format 
19. The process of claim 14 wherein data transmitted 
between said data producing processes and said data con- 
suming processes is transmitted as. sdf describing data^ 
objects, each self describing d^ object comprised of one or 
more fidds each of which is dther a primitive dass form 
which stores data or a constructed class form which is 
comprised of otiier fields which themsdves may be primi- 
tive or constructed dass forms, each said constructed class 
form belonging to a class wiach has a conEsponding dass 
definition, said self describing data objects being ori^nized 
into dasses defined by class definitions, each dass definition 
cominising a list of the fidds by name and data represen- 
tation type which are common to all self describing data 
objects of that class, each self describing data object indud- 
ing both data format information and actual data or field 
values for each said field, for providing die capability for a 
data consuming or data producing process to obtain data 
fiom a particular fidd of a particular self describing data 
object generated by anotiier process, comprising die steps 
of: 

recdviiig in a Get-Field call &om a process tiiat desires 
particular data, said Get-Held call identifying die par- 
ticular field name of die field of die self describing data 
object from which die data is to be obtained and die 
particular one of said self describing data objects firom 
which data is to be obtained; 

searching the class definition for said self describing data 
object from which data is to be obtained to locate said 
fidd name identified in said Get-Fidd call or some 
synonym thereof, 

returning a relative address for said fidd identified in said 
Get-Field call, said rdative address identifying where 
in instances of said class of said self describing data 
ol:yect identified in said Get-FIeld call said fidd named 
in said Get-Field call can be found; 

accessing said sdf describirig data ol^ject identified in said 
Get-FIdd call and retrieving the desired data using said 
rdative address of the field in which the desired data is . 
stored, and returning dm desired data to the process 
which requested said data. 

The process of claim 14 wherein the step of automati- 
cally setting up a communications link further comprises the 
steps of: 

sending a subscription request iiiessage to a publisher side 
service disdpline process which controls one or more 
of said computers so as to be coupled to recdve data on- 
the subject of said subscription request from a data 
producing process or processes which control tie same 
said one or more con[q)uters having said publisher side 
service disdpline process in execution thereon so as to 
publish data messages on said subject and with which 
communication links are to be set up on said subject; 
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recordu^ all said subscription requests in a subso^ition 
table or list; 

assigning a channel on said one or more data paths and/or 
one or more netwoiks to each said subject for which 
there is an active subscriptian and icbordiiig said Chan- 5 
nel in said subscription table for each; 

when a data message is published by any said data 
producing process, checking the subject thereof against 
the sul^je^ of all active subscriptions in said subscrip- . 
tion table or Hst to detennine if there are any active lo 
subscriptions on the subject; 

sending said data message published by any data produc- 
ing process to all data consuming processes having 
active subscriptions to the subject of said data by a 
broadcast communication protocol by dividing said 15 
data message into one or more sequential packets 
suitable for transmission over said data path and/or 
network, each sequential packet having a header and 
adding to said header the channel number assigned to 
said subject and a sequence number indicating where 20 
said packet lies in the sequence of packets which, taken 
togeth^, conqmse the data message published by said 
data publishing process, and calculating error coirec- 
tion bits on data within each said packet and adding 
said enor conectioa bits so calculated to each said 2s 

Storing all said padcets in a retransmit memoiy; 
sendiiQ messages to each data consuming process having 

an active subscrq)tian to the subject of said data 

informing each data consuming process of the channel ^0 

on which said data will be broadcast; 
broadcasting said data packets on said channel assigned to 

the subject of said data via said data path and/or 

networic; 

35 

receiving said padcets at the location of each computer in 
smd computing environmoit and, at the location of 
each said computei; comparing the channel number of 
each said packet so received to the channel numbers 
recorded in said subscription table of all active sub- ^ 
scriptions initiated by any data consuming process in 
execution at the location of said computer, 

if the channd number of the received packets at any 
computer in said computing environment matches the 
channel number of any active subscription recorded in 45 
said subscription table of a data consuming process in 
execution on said conqiuter, checking the sequence 
numbers of all packets received at the location of said 
computer in said computing oivironment to determine 
if all packets comprising the complete data message 50 
have been received and using said error correction bits 
to detennine if each received packet has been correctiy 
received, and repeating this process at the location of 
each said computer, and if the channel number of the 
received packets at any computer in said conq)uting 55 
environment does not match the channel number 
recorded in said subscription table of a data consuming 
process in execution on said computer, discarding all 
said packets whose channel numbers do not match the 
channel number recorded in said subsmption table of ^ 
a data consuming process in execution on said com- 
puter, 

if all packets have been successfully received, sending a 
message back to the process that transmitted the data 
that all packets have been successfuUy received, or, if 65 
any packet was not received or was not correctiy 
received, sending a message to the process that trans- 
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mitted the data requesting retransmission of any pack- 
&s wtucfa were not received or which were not cor- 
rectly received and which cannot be conected at the 
receiving computer using said enor correction bits; 

retransmitting any packets that were not received or 
which were not correctly received to any computer in 
said computing environment that transmitted a message 
indicating one or more packets were not received or 
were not received correctly; 

verifying that the newly transmitted packets have been 
received and have hten correctly received; and 

reassembling said data packets into said data message at 
the location of any conqniter which received data 
packets having channel numbers tnntehing the channel 
number of an active subscription entered by a data 
consuming process in execution on said computer, and 
passing 'said reassembled data message to ' the data 
consuming process or processes which requested data 
on the subject of said data message which is in execu- 
tion on said computer 

21. The process of daim 14 wherein the step of setting up 
a communications link further comprises the steps of. 

sending a subscription request message to a publisher side 
s^ce disdpline process which controls one or more 
of said computers so as to be coupled to receive data on 
the subjea of said subscription request from a data 
producing process or processes which control the same 
said one or more computers having said publisher side 
service disdpline process in execution thereon so as to 
publish data on the subject cxf said subscription request; 

lecordiiig all said subscription requests in a subscription 
table and storing in said table die identities of all data 
consuming processes desiring data on each subject 
which is the subject of an active subscription; 

assigning a channel on said one or more data paths and/or 
one or more networks to each said subject for which 
there is an active subscription and recording said chan- 
nel in said subscription table for each said subscription 
recorded therein; 

when data is published by any said data producing process 
with which a communication link has been established, 
checking the subject thereof against the subjects of all 
active subscriptions in said subscrq)tion table to deter- 
mine how many data consuming processes have active 
subscrq)tions on the subject; 

comparing the number of said data consuming processes 
to a predetermined threshold, and detenmning whether 
it would be more efiGdent to transmit the data to all data 
consuming processes having active subscriptions on 
said subject using a point-to-point communication pro- 
tocol by sending the same data multiple times over said 
one or more data paths and/or one or more networics, 
one said point to point communication being addressed 
to each data consuming processes having an active 
subscription to the subject of said data or by broad- 
casting said data on a predetermined channd on said 
one or more data paths and/or one or more networks; 

sending said data to all data consuming processes having 
active subscriptions to the subject of said data by said 
point-to-point ccnmnunication protocol if said point-to- 
point communication protocol is most effident; 

sending said data to all data consuming processes having 
active subscriptions to the subject of said data by a 
broadcast communication protocol if said broadcast 
communication protocol is most effident; 
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if said broadcast communication protocol is selected, 
dividing said data into one or more sequential packets 
suitable for transmission over a data path, each with a 
header and adding to said header the channel number 
assigned to said subject and a sequence nimiber indi- s 
eating where in the sequence of packets which, taken 
together, comprise the data message published by said 
d^ publishing process, and calculating error correc- 
tion bits on each packet and adding said error correc- 
tion bits to each said packrt; 

storing all said packets in a retransmit memory; 

sending messages to each data consuming process having ' 
an active subscription to the subject of said data 
infonning each data consuming process of the cbamiel 
on which said data will be broadcast; 13 

.broadcasting od said one or more data paths and/or said 
one or more networks said data packets via said chan- 
nel on said one or more data padbs and/or one or more 
networks assigned to the subject of said data; 

leceiving said packets at each said computer in said 20 
computing environment and, at each said con^uter, 
comparing the channel niunber of each said packet to 
the channel numbers of all active subscriptions listed in 
said subscription table entered by a data consuming 
process in execution on said computer, 2s 

if the channel number of packets received at a computer 
in said conqniting environmmt matches the channel 
number of any active subscription listed in said sub- 
scription table entered by a data consuming process in 
execution on said computer, checking the sequence 30 
numbers of all packets received to determine if all 
packets have been received and using said error cor- 
lectioa bits to determine if each packet has been 
correctly received and to correct any errors which can 
be corrected at the receiving computer using said error 35 
correction bits, and if the channel number of packets 
received at a computer in said computing environment 
does not match the. channel number of any active 
subscription fisted in said subscription table entered by 
a data consuming process in execution on said com- 40 
puter, discarding all such packets; 

sending a message back to the process that transmitted 
said packets that all padcets have been successfully 
received, or, if any packet was not received or was not 
correctly received, sending a message to the process 
that transmitted said packets requesting retransmissicm 
of any packets which were not received or which were 
not conectiy received; 

retransmitting any packets that were not received or 
which were not correctiy received; '° 

verifying tiiat the newly transmitted packets have been 
received and have bc^ correctiy received; and 

reassembling said data packets into a data message and 
passing the data packets to the data consuming process 55 
or processes wbich requested data on the subject. 

22. The process of claim 17 wherein the step of setting up 

communicaticHis link further comprises the steps of: 

sending a subscription request message to a publisher side 
service discipline process which controls one or more 60 
of said computers so as to be coupled to receive data on 
the subject of said subscription request firom a data 
producing process or processes with which communi- 
cation Unks axe to be set up on said subject and which 
control the same said one or more computers having 65 
said publisher side service discipline process in execu- 
tion thereon; 



90 

recording all said subscription requests in a subscription 
table and storing in said table the identities or addresses 
of all data consuming processes desiring dam on each 
subject which is the subject of an active subscription; 

assigning a channel on said one or more data paths and/or 
one of more networks to eadi said subject for which 
there is an active subscription and recording said chan- 
nel in said subscription tkble for each said subscription 
recorded therein; 

when data is published by any said data producing process 
with which a communication link has been established; 
checking the subject thereof against die subjects of all 
active subscriptions in said subscription taUe to deter- 
mine bow many data consuming processes have active 
subscriptions on die subject; 

conqjaring die number of said data consuming processes 
to a predetermined threshold, and determining whether 
it would be mote effidcnt to transmit the data to all data 
consuming processes having active subscriptions on 
said subject using a point-to-point cominiinication pro- 
tocol by sendmg the same data multiple tinnBS over said 
one or more data paths and/or one or more networks, 
one said point to point communication being addressed 
to each data oonsuiniiig processes having an active 
subscription to the subject of said data message or by 
broadcasting said data message on a predetermined 
channel on said one or more data paths and/or one or 
more networks and sending a message to all data 
consuming processes having active subscriptions on 
said subject to listen for data on the subject of said 
active subscriptions on said predetermined channel on 
said one or more data paths and/cn* one or more net- 
works; 

sending said data message to all data consuming pro- 
cesses having active subscripticms to the subject of said 
data by said point-to-point conmiunication protocol if 
said point-to-point oommunication protocol is most' 
efficient; 

sending said data message to aU data consuming pro- 
cesses having active subscriptions to the subject of said 
data message by a broadcast communication protocol if . 
said broadcast cornmunicarion protocol is most effi- 
cient; 

if said broadcast communication protocol is selected, 
dividing said data message uito one or more sequeiuial 
packets suitable for transmission over a data padi, each 
with a header and adding to said header the channel 
numb^ assigned to said subject and a sequence number 
indicating where in the sequence of packets which, 
taken together, comprise the data published by said data 
publishing process, and calculating error correction bits 
and adding said error correction bits to each saiid. 
packet; 

storing all said packets m a retransmit memory; 

broadcasting on said one or more data paths and/or said 
one or more networlcs said data packets on said channel 
on said one or more data paths and/or one or more 
networks assigned to the subject of said data; 

receiving said packets at each said computer in said 
computing enviroimient and, at each said computer, 
comparing the chaimel number to the cfaarmel numbers, 
of all active subscriptions listed in said subscription 
table entered by a data consuming process in execution 
on sud computer, 

if die chaimel number of padceu received at a computer 
in said computing environment of a packet matches the 
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channel ninnber of any active subscription, listed in 
said subscription table entered by a data consuming 
process in execution on said computer, checking the 
sequence numbers of all packets received to determine 
if all packets have been received and using said error 
correction bits to determine if each packet has been 
concctly received and to correct any errors which can 
be corrected at the receiving computer using said error 
conecdon bits, and if the channel number of packets 
received at a computer in said computing environment 
does not match the channel number of any active 
subscription listed in said subscription table entered by 
a data consuming process in execation on said com- 
puter, discarding all such packets; 

sending a message badcto the data pTOdnciog process that 
all packets have been successfully received, or, if any 
padcet was not reed ved or was not correctly xecdved, 
'sending a message to the daui prodiidhg 'process that 
published the data requesting retransmission of any 
packets which were not recdved or which were not 
correctly received; 

retransmitting any packets that were not received or 
which were not correcdy received; 

verifying dial die newly transmitted packets have been- 
recdved and have been correctly recdved; and 

reassembling the data packets into the original data mes- 
sage and passing the data message to the data oonsum- 
ixig process or processes which requested data on die 
subject 

23. An apparams for obtaining data requested by one or 
more data consuming processes in execution on one or more 
computers from one or more service instances in execution 
on one or more hosts or server computers, comprising: 

one or more networks or odier data paths for transporting 
data between processes running at various locations or 
addresses on said network(s), said transport of data 
being carried out on one or more tqspropriate commu- 
nication paths through said netw(nk(s) or other data 
path(s), and according to one or more q^propriate 
communication mechanisms or transport protocols; 

one or more host and/or server conqmters coapled to said 
network(8). each having one or more network 
addresses, each host and/or server computer having an 
(^)erating system and one or more other prooess(es), 
data consuming process(es) or sovioe instance(s) in 
execution thereon, each of said operating system(s), 
pn)cess(es), data consuming process(e8) or service 
instance(s) being programmed in any selected pro- 
gramming language, each said host and/or server com- 
puter having any sdected machine architecture or type 
including any appropriate machine instruction set and 
any appropriate data representation format or type, 
each of said operating systcm(s), process(es) and/or 
service imtance(s) having one or more sqipropriate 
communication, access and/or invocation protocoi(s); 

one or more computers having in execution thereon one or 
more data location and access programs which control 
processing by said one or more computers, said data 
location and access programs being coupled to said one 
or more data consuming process(es) and said one or 
more other process(es) and/or service instanoe(s), for 
recdving one or more requests for desired data &om 
said one or more data consuming processes, said 
request defining the identity of the desired data by an 
identifier comprising one or more parts, said desired 
data having certain access requirements including but 
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not limited to the particular communication patfa(s) 
tiirough said network(s) or other data patii(s) to said 
desired data, die transport protocol or protocols along 
said communication path(s) through said network(s) or 
other data path(s) to said desired data, the network 
addrBss(es) of die host(s) and/or server coiiqNitB3t(s) on 
which the proce5s(es) publishing the desired data is or 
were in execution, die machine architecture(s) or 
type(s] or operating system(s) or the datarepresentation 
fcnmat or type of the ho8t(s) andAnr server computcr(s) 
upon which the pn)cess(es) publishing the desired data 
is or were in execution, the particular pn)cess(es} 
and/or service instanoe(s) or the programming lan- 
guage(s) of the particular process(es) and/or service 
instance(s) which is or were publishing said desired 
data, and the communication, access or invocation 
prDtocol(s) which must be invoked to communicate, . 
access or invoke said prDcess(es) or sovice in8tance(s) 
which is or were publishing said desired data or the 
transport protocol(s) or operating system or systems in 
execution on any of said host or server computers 
involved in accessing and transporting said desired data 
from the prDcess(es) which publish or distribute said 
desired data to the data consuming process which 
requested said data, all of said access reqwrements 
uniquely defining the attributes of a communication 
medianism between said data consuming process(es) 
desiring said data and said desired data itself, said 
request for said desired data and said data consuming 
process which made said request being independent of 
one or more of sdd access requirements or attributes 
including at least the identity and/ar location of said 
one or more particular process(e8) and/or service 
instance(8) that publish or (tistribute said requested data 
and said communication* access or invocation protocol 
or protocols needed to communicate widi said one or 
moTB process(es} and/or service instance(s) that publish 
or distribute said requested data as well as the location 
or address of the one or more computer(s) being 
controlled by said one or more processes and/or service 
instance(s) that publish or distribute said requested 
data, said independence meaning that the data consum- 
ing process which requested said d^ired data need 
include no program, code or data die purpose of which 
is to satisfy any of said access requirements, said one 
or more computers processing of which is controlled by 
said one or more data location and access programs 
bdng controlled thereby so as to automatically satisfy 
all said access requirements so as to establish a com- 
munication path(s) to said desu^ data, access said data 
and return said data to said data consuming process(es) 
that requested said data, and wherein said one or more 
process(es) and/or service instance(s) that publish or 
distribute said requested data also do not include any 
program, code or data the purpose of which is to satisfy 
any said access requirement, other than to output the 
subject itself of die data being published, or the purpose 
of which is to direct where said data is to be transmitted 
or to assist in any other way in satisfying any other of 
said access requirements. 
24. The i^params of claim 23 wherdn said one or more 
data location and access programs indude one or more data 
format decoupling programs coupled to said one or more 
conqniters having in execution thereon said one or more data 
location and access programs, said one or more data format 
decoupling programs for providing data representation inde- 
pendence such that data may be eflfectively obtained by said 
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one or more data consuming prbcess(es) which requested 
said data tegaidless of the particular data rq)resentation 
fQiinat(s) or type(s) used by said one or more data consum- 
ing pn)cess(es) and whatever pn)cess(es) or service 
instance(s) which publish the requested data. 5 

25. The f^paratus of claim 24 wherein said one or more 
data format decoupling programs further comprise means 
coupled to said one or more data consuming process(es) and 
said one or more process(es) and/or service instance(s) 
which publish the requested data for creating, manipulating, iO 
storing and transmitting self-describing data objects which 
include not only data but also data representation format 
information within each instance of a self describing data 
object 

26. The ^aratus of claim 23 wherein said one or more is 
data location and access progr am s include one or more 
service discipline programs for encapsulating af^sopriatB 
software routines for communicating with one or mare of ' 
said piocess(e8) and/or service instanc6(s) which publish 
said requested data in the oorniminication, access and/or 20 
invocation piotocoUs) native thereto. 

27. Hie ai^nratus of claim 24 n^erein said one or more 
oomputeis having in execution thereon said one or more data 
location and access programs for receiving said request(s) 
for desired data also are pn^rammed to implement one or 25 
more service disdpUne means for encapsulating and execut- 
ing ^Tpropriate software routines for controlling one or more 
computers so as to communicate with one or more of said 
process(es) and/or service instance(s) which publish said 
requested data using the communication^ access and/or 30 
invocation protocol(s) native thereto, and wherein said self- 
describing data objects are organized into classes, each of 
which has common attributes and a unique class identifier, 
and wherein each self describing data object has one or more 
fields, each field being either primitive in that die field stores 35 
data or constructed in that the field stores data which is the 
class identifier of another class of self desctiMng data 
objects and the data from an instance from said other class. 

28. The apparatus of ckdm 23 wherein said one or more 
data location and access programs includes Subject-Ad- 40 
dressed Subscription Service means for controUing said one 

or more con^niters to implement a programmatic interface 
to said one or more data consuming and data pnblishmg 
processes, said progranunatic interface in^ementing a sub- 
scribe function which can be invoiced by a data consuming 45 
process by ou^puttii^ a a subscription request requesting 
data by identifier only, said data and all updates thereto 
published under said particular identifier by one or more of 
said pn)cess(es) and/or service instance(8), and for automati- 
cally establishing a communication path between at least so 
one of said data consuming processes which requested said 
data by identifier only and at least one of said processes 
and/or service instances which publish said requested data 
having said identifier until said subscription request is 
canceled, said progranmiatic interface also for controlling 55 
one or more conq)uters having one or more service instances 
in execution thereon such that service instance(es) can 
publish data simply by involdng a publish function of said 
programmatic interface arid outputting the data and the 
identifier of the data, and wherein said computer(s) con- 60 
trolled by said programmatic interface will use the identifier 
of said published data to automatically route the data to only 
those computers having in execution thereon a data con- 
suming process having an open subscription to data having 
said identifier and to no other computer, said programmatic 6S 
interface also controlling one or more computers such that 
when said process(es) and/or service instance(s) publish 
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updates to said requested data with an identifier, said idoi- 
tifier is used to transmit said updates automatically to said 
one or more data consuming processes which requested said 
data for which said conununication path(s) has or have been 
established and to only those computers having in execution 
tiiereon data consuming processes having open subscrip- 
tions to data having said identifier imtil said subscription is 
canceled. 

29. The ^)paratus of claim 25 wherein said self-describ- 
ing data objects are organized into classes, each of which has 
conunon attritnites and a unique class identifier, and wherein 
each self-describing data object has one or more fields, each 
field being either primitive in that the field stores data or 
constructed in that the field stores data which comprises the 
class identifier of another dass of sdf-desaiUng data 
objects and the data from an instance from said other dass. 

30. The apparatus of claim 28 ^^^lerem said one or mote 
^data location' and access programs further further cacaptises 
means, coiipled to said one or more data ccxisuming pro- 
cesses which requested said data and said one or more 
process(es) and/or s^ce instance(s) which publish said 
requested data, for creating, manipulating, storing and trans- 
mitting said requested data as sdf-describing data objects 
which indude not only data but also said data representation 
format or type information within each instance of a data 
object 

31. The apparatus of daim 30 wherein said self-describ- 
ing data dejects are organized into classes, each of which has 
oonmdon attributes and a unique dass identifier, and wherein 
each self-describing data object has one or more fidds, each 
field bdng either primitive in that the field stores data or 
constmcted in that the field stores data which comprises the 
class identifier of another class of self-describing data 
objects and the data from an instance from said other dass. 

32. The apparatus of daim 28 wherein said one or more 
data location and access programs include one or more 
service disdpline means, each for controlling one or more of 
said computers for oommimicating with one or more of said 
processes and/or service instances which publish said 
requested data in the commuoication, access or invocation 
protocoUs) native thereto. 

33. The apparatus of daim 31 wherrin said one or more 
data location and access programs indude one or more 
programs which control said one or more computers to 
implement one or more service disdpline means, each for 
communicating with one or more of said processes and/or 
service instances wMch publish said requested data in die 
communication, access or invocation protocol(s) native 
thoeto. 

34. The appamtiis of claim 28 wherein said one or more 
computen having in execution thereon said one or more data 
location and access programs also are programmed to also 
implement means for establishing said communication path 
by listening for data messages from any source arriving at 
one or more network pod address(es) assodated with said 
one or more data consuming processes which requested said 
data and filtering out all data messages other than data 
messages whidi have said identifier assodated with said 
requested data, and passing all said messages having said 
identifier of said requested data to any said one or more 
computers having in execution thereon said one or more data 
consuming pnicess(es) which issued said rBquest(s) for said 
data and for which said communication path has been 
established. 

35. The apparatus of claim 28 wherein said one or more 
data location and access programs include one or more 
programs to control one or more of smd oonqnuers so as to 
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implement subscripdon registration means for establishing 
said communication path by sending a subscription regis- 
tration message to register said subscription for said desired 
data with the one or more computers having in execution 
thereon said one or more data location and access programs 
which are coiqiled to said proces$(es) and/or service 
instances which publish said requested data, said subscrip- 
tion registrati<m message induding the identifier of the 
requested data, and whoein said at least one process and/or 
service instance which publishes said requested data is 
coupled to said one or more connputefs inq)lementing said 
subscription registration means and wherein said one or 
more computers havixig in execution thereon said one or 
more data location and access programs is also programmed 
to implement means for transmitting data published by said 
at least one process and/csr service instance wMdi has an 
identifier whidi matches the identifier for riK[iiested data 
which is the subject ojf any active subscription registration to 
all the data consuming process(es) which registered a sub- 
SOTption to data having said identifien 

36. The apparatus of claim 32 wherein each said computer 
programmed to implement said one or more service disci- 
pline means is also programmed to implement means for 
failure recovery so as to be able to Tnaintflin the flow of data 
to said one or more data consuming process(es) which 
requested said data despite failure of said conununication 
padi, host and/cH* server computer(s) or process(es) and/or 
service instance(s) which is publishing said requested data. 

37. The apparatus of claim 28 wherein said Subject- 
Addressed Subscription Service means includes service dis- 
cipline means for controlling said one or more computers to 
carey out communication of data over said communication 
path to fulfill said subscription request usii^ a conmumica- 
tion protocol which is appropriate for the one or more 
processes and/or service iostanoes wMdi are supplying said 
data, and wherein said one or more data location and access 
programs include one or more programs for controlling said 
one or more computers to implement one or more protocol 
engines, said protocol engines for establishing said commu- 
nication palh(s) using the sqypropriate network or commu- 
nicadon path transport protocols for the communication path 
through which said requested data is obtained and for 
interfacing said service discipline means to said network or 
conmmnication path transport protocols. 

38. The apparatus of claim 25 wherein said one or man 
data location and access programs include means for imple- 
menting one or more service disciplines for controlling said 
one or more computers to conmmnicate with service 
instances in the conmiunicadon, access oc invocation piro- 
tocol tmtive thereto, and wherein said one or more data 
location and access programs coupled to said one or more 
other process(es) and/or service instance(s) and said one or 
more data consuming process(es) include protocol engine 
means for controlling one or more computers to receive 
requests from said service disciplines to establish a com- 
munication path through which said requested data may be 
obtained, and assisting said one or more computers con- 
trolled by said service disciplines so as to establish said 
communication path(s) by interfacing said one or more 
CQnq»utecs controlled by said one or more service disciplines 
to the appropriate network or canmnmication path transport 
im)tocols for the communicatmn path throu^ which said 
requested data is to be obtained. 

39. The apparatus of claim 37 wherein said protocol 
engines include means for controlling said one or more 
computers to cany out a reliable broadcast communication 
protocol. 
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40. The apparams of claim 39 wherein each said protocol 
engine controls said one or more computers so as to have 
different fault tolerance characteristics not already imple- 
moued by said transport protocols. 
5 41. The apparatus of daim 38 wherein said one or more 
. computers controlled by said protocol engine means is is 
controlled so as to cany out a reliable broadcast communi- 
cation protocol if the number of subscribers to data having 
a partiailar identifier is greater than a prpgranunable number 
and is controUed to carry out a point-to-point conununica- 
tion protocol it the munber of subscribers is less than said 
programmable number. 

42. Ibe ^aratus of claim 41 wherein each said a 
protocol engine controls said one or more computers so as 
to have different fault tolerance characteristics. 

43. The s^arams of daim 23 or 28 wherein said 
requested data is transported over said communication path 
using one or more data messages, and wherein said one. or 
more data location and access programs includes means for 
transporting said requested data over said oommimication 

20 path using a reliahle communication protocol which insures 
that all data messages were received without error. 

44. The apparatus of daim 23 or 28 wdierein said one or 
more data location and access programs indudes reliable 
broadcast transmit means coupl«l to said process(es) and/or 

25 sorvioe instance(s) which publish said requested data, said 
reliable broadcast transmit means for dividing data messages 
into padcets for transmission on said networic and adding 
sequence numbers to said padcets, and for calculating enor 
correction bits for each padret and adding said enor oor- 

30 rection bits to said padcets, and for temporarily storing 
padcets to be transmitted over said network in a retransmit 
memory, and for broadcasting said packets over said net- 
work or communication padi, and wherein said one or more 
data location and access programs forther conqmse recdve 

35 means coupled to said data consuming processes which 
requested said data for listenixig to a network address 
associated with at least one of said data consuming pro- 
cesses which requested said data and sdecdng incoming 
packets which comprise a complete data message of said 

40 requested data and checking the sequence numbers of 
incoming packets to insure that all data messages compris- 
ing said requested data have been received, and for using 
said error correcdon bits of each packet to detect and correct 
errors in said received packets, and, if any data message was 

45 not received or contains errors not correctable using said 
error correction bits, for sending a message back to said 
reliable broadcast transmit means requesting retransmission 
&om said retransmit memory of any data messages not 
recdved or not recdved correctly. 

50 45. The q)paratus of daim 23 or 28 wherein said one or 
more data location and access programs forther comprises 
an intelligent nmlticast program for controlling one or more 
computers so as to determine how many data constmiing 
processes have open subscriptions to data with a particular 

55 identifier and for controlling said one or more computers to 
broadcast data messages having said identifier when the 
number of data consuming processes requesting said data is 
greater than or equal to a predetermined number, and for 
sending said data messages directly to the data consuming 

60 process or processes which requested said data by a point- 
to-poim conununication protocol when the munber of said 
darn consuming processes which requested said data is 
bdow said predetermined number, said predetermined num- 
ber sdected such that the most efSdem means of transpon- 

65 ing said data is used in terms of consumption of network or 
conmiunication path bandwidth and consumption of com- 
puting itsources. 
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46. The apparatus of claims 23 or 28 wherem said one or 
more computers having in execution thereon said one or 
more data location and access programs are controlled 
thereby so as to implement means for chocking the identifier 
of said requested data and die identity or identities of said 5 
data consuming processes which requested said data against 

a list of authorized identifiers associated with each of said 
one or more data consuming processes which requested said 
data, and for blocking access by any data consuming process 
to any requested data having an identifier not on the list of 
authorized identifiers for said data consuming process, 

47. Hie apparams of claim 23 or 28 wherein said one or 
more computers having in execution tfaeieon one or more 
data location and access programs are also programmed by 
said one or data location and access programs to implement 
means for switching communication paths through s aid 
netwQik or other data communication path upon failure of 
the selected commimicationpathorotfaerinteiniptions in the - 
flow of data so as to maintain tiie flow of data to all data 
consuming processes having open subscriptions. ^ 

48. An apparams for use in a distributed computing 
environment, comprising: 

one or more con^uters coupled by one or more data 
paths, said one or more computers having in execution 
thereon one or more {plication processes controlling 2s 
processing of said one or more computers, and wherein 
at least one of said application processes is a data 
consumer process needing data on one or more subjects 
and capable of outputting a 8ubscr^)tion request for 
each subject for which data is desired, each said sub* 30 
scription request including a subjea for which data is 
requested but wherein no data consumer process needs 
to include any routine which controls one more of said 
computers so as to output any infbrmation, address data 
or address related data indicating where said data may 35 
be found in said distributed computing environment 
other than outputting die subscription request and the 
subject thereof, and wheim at least one of said appli- 
cation processes is a data publisher process whidi 
outputs data messages on various subjects but which 40 
does not need to include any routine tiie purpose of 
which is to output any address or address related data, 
other than the subject itsdt which indicates where said 
data messages are to be transmitted m said distributed 
computing environment or in any other way assist in 45 
the distribution of said data; 

one or more computes processing of which is controlled 
by one or more directory services programs or nmtines 
so as to, when given a subject, access and search adata 
file, said data file storing data records mapping data so 
publisher processes to subjects, each said data record 
containing a subjea and identity and/or address data 
specifying, directly or indirectiy, the address in said 
distributed computing environment of one or more 
sources of data messages on said subject, each said S3 
source obtaining said data messages on said subject 
from one or more data publisher processes in said 
distributed computing environment which publish data 
on said subject, and wherein each source on any 
particular subject comprises one or more conqniters 60 
controlled by one or more computer programs so as to 
receive messages firom a data publisher process on the 
subjea corresponding to said source and re-transmit 
said data messages on the subjea to only those data 
consumer processes which have open subscriptions for 65 
data messages on the subject, said one or more diiec- 
toiy services programs or routines for controlling said 
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one or more comput»^ so as to return any data record 
in ^d data file identifying and/or giving the address in 
said distributed computing environment of one or more 
sources which can output data on said subjea Uiat was 
originally passed to said one or more computers oil 
which said one or more directory services programs or 
routines are in execution; 

one or more computers controlled by one or more map- 
ping programs or routines so as to receive each said 
subscription request fioom a computer on which a data 
consumer process is in execution, said subscription 
request idoitifying only a particular suligea for which 
a subscripti(m is requested, said one or more meppmg 
programs or routines for controllii^ said one or more 
computers so as to map the subjea of said subsoiption 
request direoly or indirectly to the identity and/dr 
address in said disnibuted computing environment of 
one or more sources which caii biSput data tnessages mi ' 
said subject, said mapping carried out by said one or 
more computers controlled by said one or more map- 
ping programs or routines by passing the subjea of said 
subscription reque^ to said one or more con^ters 
controlled by said at least one directory services pro- 
gram or routine so as to cause said one or more 
con^niters controlled by said one or more directory 
services programs or routines to search said data file for 
a data record(s} identifying and/or giving the address in 
said distributed computing environment of one or more 
sources which ou^ data on said subjea and control- 
ling said one or more computers on which said one or 
more m^iping programs or routines are iii execution to 
receive ssdd data records resultir^ from said search, 
said one or more mapping programs for controlling said 
one or more computers so as to output at least said 
identity or address data in a link request requesting the 
establishment of a subscription comnmnication link 

' with said one or more sources identified in said data 
records resulting from said search; 

one or more oomputeis controlled by one or more sub- 
scription registration and, communication programs or 
routines so as to receive said identity and/or address 
data in said Unk request ficom said one or more com- 
puters controlled by said one or more mapping pro- 
grams or routines, said link request conesponding to at 
least oac subjea and a corresponding subscription 
request, said subscription registration and communica- 
tion programs or routines for controlling said one or 
more computers so as to automatically establish a 
communication link with at least one soiux^e which 
outputs data on the subject to which said link request 
pertains via at least one said data path and automati- 
cally send a subsoiption registration message to said at 
least one source identified in said link request so as to 
notify said source of an op^ subscription on said 
subject, each said subscription registration message 
directly or indirectiy identifying and/or giving the 
address in said distributed computing environment of 
the data consumer process which issued said subscrip- 
tion request on said subject through the computer on 
which said data consumer process is in execution or 
some other process which controls one or more com- 
puters to receive data messages on the subject of said 
subscription request on behalf of said data consumer 
process 9ftdch requested tiie data and pass , the data 
messages only to said one or more computers con- 
trolled by said data consumer process which requested 
said data, said one or more subscription registration and 
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communication programs also for controlling said one 
or more computers so as to receive data messages on 
said subject whenever said data messages on said 
subject are output by said source with which said 
subscription communication link has been established 5 
and pass said data messages to said one or more 
computers being controlled by said data consumer 
process which requested data on the subject until said 
subscription is canceled; 
one or more oonqmters under control by one or more data iq 
distribution programs or routines so as to implement 
said one or more sources which output data on the 
subject of each said subscripdon request, said sources 
being selectively coupled to said one or more coxxqmt- 
ers under control of said data consumer processes aiid 
selectiveb^ coupled to said one or more computers 
under control of said data publisher processes, said one 
or more computers under control 'of said one ar rnjare 
data distribudon programs or routines for recdving 
data messages published by said one or more data ^ 
publisher processes on one or more subjects, and for 
receiving said subscription registration messages 
requesting subscriptions on one or more subjects and 
for automatically sending eadi said data message over 
said subscription communication link only to conq)ut- ^ 
ers having in execution thereon data constmier pro- 
cesses having active subscriptions to the subject of said 
data message, said data distribution programs or rou- 
tines controlling said one or more computers to so 
distribute published data without receiving any data 
from the data publisher process, other than the subject 
itself of each data message, indicating where each said 
data message on any subject is to be sent, and for 
automatically continuing to transmit each new data 
message received from a conqiuter controlled by a data 
publisher process on any subject to only data consumer 
processes having an active subscription to the subject 
of each said new data message until said subscription is 
canceled, each said data distribution programCs) or 
routine(s) containing no routines, computer program, ^ 
subroutine or other computer programming code the 
purpose of which is to recdve any data from said data 
publisher process, odier than the subject of a data 
message itself, which controls where in said disoibuted 
computing environment any said data message on any 
subject is to be sent 
49. A process for communicating data between at least 
one publishif^ process and at least one consumer process in 
execution on one or more computers in a distributed com- 
puting system, said publishing and consumer processes ^ 
coupled by a data path, comprising: . 
storing data encoding a subject space and the subjects 
therein in a memory of one or more of said computers, 
and storing in said memory data mq)ping the identity 
and/or the address in said distributed computing system 55 
of one or more source computer processes for execu- 
tion on one or more of said computers in said distrib- 
uted computing system which can supply data on a 
subject for every subject in said subject space; 
receiving at one or more computer processes in execution eo 
on one or more of s^d computers a subscription request 
from at least one consumer process, said subscription 
request specifying only the subject for which data is 
requested but not whone data on said subject can be 
found in said distributed computing system and sped- 65 
fying a manner of returning data on die requested 
subject to said consumer process; 
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in one or more computer processes in execution on one or 
more of said computers, using the subject of said 
subscription request to automatically look up in said 
stored data encoding said subject space and the subjects 
therein, the identity and/or address in said distributed 
computing system of one or more source computer 
processes which can supply data on the subject sped- 
fied in said subscription request, and automatically 
sending a subscription registration message to said 
source computer process specifying the subject for a 
subscription and spedfying tiie manner of returning 
data on the spedfied subject to the consumer process 
which requested said data, said subscription registra- 
tion message being sent to one or more subscription 
registration imx:esses in execution on said one or more 
computers the function of which is to keep one or more 
subscription lists listing all active subscriptions on each 
subject; - — 

receiving at said one or more source coiiq>uter processes 
in execution on one or mare of said coniputers one or 
more data messages from at least one publisher process 
which specify a subject and indude data to be pub- 
lished on said sul^ect but which do not specify where 
the data on said subject is to be sent within said 
distributed oomputii^ system other than by specifying 
the subject itself, and conqiaring the subject of each 
said data message to said one ox more subscription lists 
kept by said one or more subscription registration 
processes and, if one or more active subscriptions exist 
for the subject of any particular data message, auto- 
matically sending all d^ messages on the subject and 
any subsequent data messages on the same subject to 
only those computers which have consumer processes 
in execution thoeon having open subscriptions on the 
subject of said data messages, and for continuing to 
send each data message pertaining to a subject to only 
those computers having in execution thereon a con- 
sumer process having an active subscription for said 
subject until the subscription on said subject is can- 
celed. 

50. A distributed computing apparatus, comprising: 

a plurality of 30 or more computers processing of which 
is controlled by a plurality of 30 or more programs or 
subroutines, said programs or subroutines in execution 
on one or more of said plurality of 30 or more com- 
puters, hereafter r^eired to as processes, said plurality 
of processes and said plurality of computers coupled by 
one or more data paths; 

and wherein at least one of said computers has in execu- 
tion thereon at least one of said processes which is a 
subscriber process which requests data on any subject 
in a hierarchically organized subject space having 30 or 
more subjects by issuing a subscription request request- 
ing that a subscription be opened and naming the 
subject of the requested data and including data indi- 
cating how data on said subject is to be sent to said 
subscriber process, where no subscription request 
includes any data, other than the subject itself, indicat- 
ing the idoitity or locations in said distributed com- 
puting environment of any publisher process which 
ou^uts data messages on ibt subject named in said 
subscription request; 

and wherein at least one of said processes is a publisher 
process which publishes data messages on one or more 
subjects and which does not include any routine, com- 
puter code or subroutine the purpose of which is to 
receive any data, address or address related data the 
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purpose of which is to control directly or indirectly 
where data being published by said publisher process is 
to be sent in said distributed confuting environment or 
to send any data, address or address related data with 
said data messages being published, other dian the 5 
subjects themselves of the data messages, which indi- 
cates or controls directly or indirectly where in said 
distributed computiiig ipparatus to send any said data 
message; 

one or more computers under control of one or more 10 
subject-based addressing programs or subroutines said 
one or more ccnnputers under control of said one or 
more subject-based addressing pTograms or subroutiiies 
being coupled to each said publisher process and each 
said subscriber process via said one or more data paths, 15 
said one or more subject-based addressing programs 
comprising one or mcHC subscription handling routines 
~" for coatiblling execution on one or more of said 
con^mters so as to receive said subscription requests 
from said one or more subscriber processes and for 20 
keeping a list of active subscriptions of sutijects for 
which there have been subscription requests made by 
one or more subscriber processes, and for automatically 
locating, for each active subsoiption, one or more ^ 
computers onipled to or controlled by a process which 25 
can supply data on the subject of said subscription 
request, said one or more computers having their pro- 
cessing controlled by one \x more programs which 
cause said one or more computers to supply data on the 
subject of each said subscription request, and said one 30 
or more computers under contrcd of one or more 
subject-based addressing programs or subroutines for 
automatically establishing a data communication path 
for each said subscription request between the sub- 
scriber process which issued said subscription request 35 
and said one or more computers coupled to or con- 
tiolled by said process that can supply data on the 
sutject of said subscription request and automatically 
xegistering a subscription on the subjea of said sub- 
scription request on said one or more computers 40 
coupled to or controlled by said process that can supply 
data on the subj ect so as to start a flow of data on said 
subject over said data communication path previously 
established, and said one or more subject-based 
addressing programs or subroutines for controlling said 45 
one or more computers so as to pass each data message 
received from said one or more computers coupled to 
or controlled by said process which can supply data on 
the subject of said subscription request (mly to com- 
puters under control of said one or more subscriber 50 
processes having an active subsc^ption on the subject 
of each said data message. 
51. The apparatus of claim 50 wherein said one or more 
computers controlled by said one or more subject-based 
addressing programs further comprise one or more con^)ut- 55 
ers controUed by one or more published message routing 
processes so as to receive data messages published by said 
one or more computers coupled to or conuolled by said 
process which can supply da^ on the subject of each said 
subscription request, and, without receiving any data, com- 60 
mand or request from any said publisher process controlling, 
assisting in controlling or indicating where each said data 
message is to be sent, for automatically and continuously 
sending each data message published on any said subject 
only to computers controlled by subscriber processes that 65 
have active subscriptions on the subject of said data message 
using the one or more data comnmnication paths that have 
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been opened for that subject and, wherein, for each said 
subscription request, said one or more computers controUed 
by one or more published message routing processes and 
said one or more subject-based addressing programs or 
subroutines automatically carry out one or more communi- 
cation protocols and any necessary data format conversion 
operations that enable the computer controlled by a sub- 
scriber process which issued said subscription request on a 
subject to effectively communicate with the one or more 
computers coupled to or controUed by said process whids 
can supply data on the subject of said subscription request 

52. A process for communicating data between software 
processes operating in one or more computers coupled by a 
data communication path, comprising: 

storing data encoding a subject space and the subjects 
therein in a memory of one or more of said computers, 
and storing in said memory data mapping the identity 

. and/or the address of one or more source processes for 
execution on one or more of said computers which can 
supply data on a subject for every subject ia said 
subject space; 

receiving a subscription request for infmrmation on a 
particular subject from a requesting software process 
and locating at least one suitable said source process for 
data on said subject by searching said data stored in 
said computer memory encoding said subject space 
using die subject of said subscription request as a 
search criteria; and 

automaticaUy satisfying aU access requirements including 
invoking and carrying out aU necessary communication 
protocols and data fcvmat and representation conver- 
sions needed to set up a communication chaimel 
through said data communication path between said . 
source process and said requesting software process 
such that a subscription is set up whereby current data 
on die requested subject and subsequent data updates 
on the requested subject flows through said communi- 
cation channel only to computers being controUed by 
the requesting software process(cs) and are converted 
automaticaUy to the data format and representation 
used by said requesting software process(es) until said 
subscription request is canceled, aU said access rcquirer 
mcnts being satisfied, oommunication protocols 
invoked and data format conversions bdng carried out 
automaticaUy without tiie aid of atiy data from or 
processing by said source process or requesting process 
such that said requestmg software process need only 
name the subject of the desired data and said source 
process need only output data on the requested subject 
and name the subject thereof with the necessary pro- 
cessing needed to get that data to the requesting soft- 
ware process and the configuration and/or operation of 
the data communication path being transparent to said 
source process. 

53. A process for communicating data between software 
processes controUing processing of one or more computers 
coupled by a data communication path, one or more of said 
software processes being a consumer process that needs data 
and one or more of said software processes being a publisher 
process which publishes data on a subject, said publisher 
process, said consumer process and said data communica- 
tion path having access requkements, comprising: 

storing data encoding a subject space and the subjects 
therein in a memory of one or more of said computers, 
and storing in said memory data mqipmg die identity 
and/or the address of one or more publisher processes 
for execution 00 one or more of said computers which 
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can supply data on a subject for every subject in said 
subject space; 

receiving a subscription request for information on a 
particular subject from one or more consumer software 
processes where no consumer process needs to output ^ 
any data or address information which specifies where 
the desired data can be found other than the subject 
itself, and locating at least one suitable publisher pro- 
cess which can publish data on said subject by search- 
ing said data stored in said computer memoiy encoding 
said subject space using the subject of said subscription 
request as . a search criteria; and 

automatically satisfying all said access requirements 
including invoking and carrying out all necessary com- 
munication protocols needed to s^ up a communication 
channel through said data communication path between 

... said publisher process and only said computers pro- 
cessing of which is controlled by consumer software 
processes having open subscriptions on the subject of 
said subscription request sudi that a subscription is set ^ 
up whereby current data on the requested subject and 
subsequent data updates on the requested subject flow 
through said communication channel and are routed 
automatically to only computers processing of which is 
controlled by consumer software processes which ^ 
rBq|uested data on the specified sulgect until said sub- 
scription request is canceled, aH said access require- 
ments being satisfied and communication protooob 
being invoked automatically without the aid of any data 
from or processing by said publisher process, other ^ 
than by ou^ut of the subject itself, such that said 
publisher process need only output data on the 
requested subjea and name the subject thereof with no 
need for said publisher process to have therein any 
software routine which knows the locations of con- 
sumer processes having open subscriptions to the sub- 
ject or which is capable of finding the address of any 
said consumer process having an open subscription on 
the subject of the published data, with all the necessary 
processing needed to get the data published by said ^ 
publisher process to all consumer software processes 
having open subscriptions on the subject of said pub- 
lished data by nonbroadcast communicatiQn processes 
being automatically performed by middleman software 
processes other than the publisher process or the coo- 
sumer process or processes and wherein the configu- 
ration and c^eradon and communication protocols of 
the data oommunicarion path and said middleman soft- 
ware processes are transparent to said publisher process 
and said consumer process or processes. 

54. An apparatus conq}rising: 

one or more computers having one or more software 
processes in execution thereon controlling operations 
of said one or more computers, at least one of said 
software processes being a consumer process that needs 
data on a subject and at least one of said software 
processes being a publisher process which publishes 
data on one or more subjects, 

one or more data paths coupled to said one or more ^ 
computers and capable of canying data between said 
consumer and publisher processes in execution on said 
one or more camputers; 

and wherein said one or more computers have interme- 
diacy software program(s) in execution thereon for 6s 
controlling one or more of said computers to implement 
decoupled, subject based addressing whereby a con- 



so 



sumer process can obtain data pertaining to a subject 
simply by entering a subscription request by invoicing 
a subscribe function of an application programmatic 
intetfBce, hereafter referred to as an API, implemented 
by said intermediary software program(s), said sub- 
scription request only naming the subject of the desired 
data and identifying a method for getting data on the 
requested subject back to the consume process, and 
said intermediary software program(s) for controlling 
one or more counters to take the subject of said 
subscription request and automatically m^ said sub- 
ject to the identity and/or address of one or more 
publisher processes which is/are capable of supplying 
data on said subject and wherein said intcrmecfiary 
software program(s) control one or more con^utcrs to 
automati^ly set up a data communication path for 
each said subscription request between said one or 

- ^more publisher processes which publish data on the 
subject of said subscription request and only those 
con^juters being controlled by consumer processes 
having an open subscription to the subjea of ssdd 
subscription request, and wherein said API imple- 
mented by said intermediary software program(s) pro- 
vides a pid>lish function which can be invoked by a data 
publisher process when data on a subject is to be 
published thereby allowing a publisher process to have 
published data distributed to all consumer processes 
having open subscriptions to the subject of said pub- 
lished dsoa simply by invoking said publish function, 
publishing said data and nflming the subject thereof, 
and, when said publish function is invoked, said inter- 
mediary software program(s) receives the published 
data and automatically distributes said data only to 
computers OHitrolled by constuner processes that have 
active subscriptions to the subject of the published data. 

55. An apparams comprising: 

one or more computers having one or more software 
processes in execution thereon controlling operations 
of said one or more coniputcrB, at least one of said 
software processes being a consumer process that needs 
data on a subject and at least one of said software 
processes being a publisher process which publishes 
data on one or more subjects; 

one or more data paths coupled to said one or more 
computers and capable of carrying data between said 
consumer and publisher processes in execution on said 
one or more comptiters; 

and wherein said one or more computers have one or more 
intermediary software means in execution thereon for 
controlling one or more of said computers to implement 
decoupled, subject based addressing, said intermediary 
software means including one or more means for 
controlling said one or more computers to provide an 
£q)plication programmatic interface, hereafter referred 
to as an APt to each said consumer process, whereby 
each said consumer process can obtain data pertaining 
to a subject simply by entering a subscription request in 
the form of invoking a subscribe function of said API 
implemented by said intermediary software means, said 
subscription request naming the subject, and wherein 
said intermediary software means includes one or more 
mapping means for controlling said one or more com- 
puters to automatically map the subject of said sub- 
scription request to the identity and/or address of one or 
more publisher processes which is/are enable of sup- 
plying data on said subject, and wherein said iiUerme- 
diary software means includes one or more means for 
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controUing said one or more computers to automati- 
cally establish a data oommunication path between all 
consumer processes having open subscriptions on a 
subject and one or moie publisher processes which can 
publish data on the subject, and wherein said intenne- 5 
diaiy software means includes one or more means for 
implementing a publisher side API to provide a facility 
such that a data publisher process can invoke a pubH^ 
function when ^ta on a subject is to be published, and 
wherein said intermediary software means is also for to 
controlling one or more computers to receive the pub- 
lished data when said publish function of said publisher . 
side API is invoked and distribute said data automati- 
cally to only oomputers controlled by consumer pro- 
cesses that have active subscriptions to die subject of 15 
the published data and without the need for said pub- 
lisher process to include any data or software toudnes 
that dbntaiiis of output the addresses of my consumer 
process or which is designwl to dpsignale to wUcfa 
consimier processes said data is to be distributed or 20 
which is designed to locate any consumer process 
which has an open subscription to data on the subject 
of said published data or any other subject 
56. An apparatus for facilitating communication of data in 
a distributed system between two or more computer pro- 25 
grams in execution on the same or different computers 
coi^led by a data exchange medium, comprising: 
a network comprised of at least one data transfer path, 
said network coupling said one or more computers by 
one or more data transfer paths^ ^ 
at least one computer execution of which is oonlrolied ^ 
one or more application computer programs, said appli- 
cation computer program controlling said one or more 
computers by Issuing a siibscription request for data on 
a subjea named In said subscription request; ^ 
at least one computer execution of which is controlled by 
one or morz data publishing computer programs whidi 
may or may not be the same as said plication 
computer program, said data publishing conq)uter pro- ^ 
gram controlling execution on at least one said com- 
puter so as to output data on at least one subject; 
one or more compiters contndled by one or more subject 
based addressing programs so as to logically decouple 
said one or more ^)plication computer protgrams fiom 45 
said one or more data puUsshing computer programs by 
providing an plication programmatic interface to said 
one or moro q>plication computa* programs such that 
said one or more i^lication computer programs need 
not have any routines therein to locate or communicate 50 
with any other compute or computer program to obtain 
data on a subject other than to issue said subscription 
request through said ai^lication programmatic inter- 
face to said one or more computers controlled by said 
subject based addressing program and said one or more 
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computers controlled by said subject based addressing 
program will automatically locate a computer con- 
trolled by a data publishing computer program which 
publishes data on said subject and will obtain data on 
said subject and pass said subject to said apptication 
computer program which is^ied said subscription 
request thereby insulating said application con^mter 
programs from obsolescence when changes or substi- 
tutions occur in the one or mote data publishing com- 
puter programs which controls said one or more com- 
puters to publish data requested by said one or more 
q)pllcation computer programs, said subject based 
addressing programs also for controlling said one or 
more computers such that data published by one or 
more computers controlled by one or more data pub- 
lishing coniputer programs that is on a subject for 
- - y/toKh Ifaere is no active subscription is filtered out fay 
the one or more computers executing said one or more 
data publishing computer programs such that said data 
is never transmitted on said networic, said subject based 
addressmg programs also for controlling said one or 
more computers such that data published by said one or 
more conqaiters executmg said one or more data pub- 
lishing computer programs that is on one or more 
subjects for which there are active subscriptions Is 
transmitted only to computers controlled by said one or 
more application computer programs that issued subr 
scription requests on the subject of said data, said 
subject based addressing programs also for controlling 
said one or more computes such that an application 
programmatic interface is presented to one or more said 
data publishing programs such that said one or more 
counters executing said data publishing programs can 
transmit data published on a subject for which there is 
an active subscription only to those computers execu- 
tion of which is controlled by one or more ^plication 
con^ter programs which requested said d^ by out- 
putting said data and the subject thereof tiirou^ said 
Implication progrannmatic mterface to said one or more 
computers controlled by said one or inore subject based 
addressmg computer programs such that said one or 
more data publishing need not include any routines or 
con^ter program instructions designed to locate or 
communicate with any computer controlled by one or 
moro ^plication computer programs otiier than to 
output data and the subject thereof through said appli- 
cation p im g ramwifitin jnterfece thereby insulatii^ said 
data pui)li^iing computer programs from obsolescence 
when changes or substitutions occur in the one or more 
application computer programs which controls said one 
or more oomputers to request data published by said 
one or more data publishiog con^ter programs. 

« « * * • 
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[57] ABSTRACT 

A design control system suitable for use in connection with 
the design of integrated circuits and other elements of 
manufacture having many parts which need to be developed 
in a concurrent engineering environment with inputs pro- 
vided by users and or systems which may be located 
anywhere in the world providing a set of control information 
for coordinating movement of the design information 
through development and to release while providing 
dynamic tracking of the status of elements of the bills of 
materials in an integrated and coordinated activity control 
system utilizing a repository which can be implemented in 
the form of a database (relational, object oriented, etc.) or 
using a flat file system. Once a model is created and/or 
identified by control information design libraries hold the 
actual pieces of the design under control of the system 
without limit to the number of libraries, and providing for 
tracking and hierarchical designs which are allowed to 
traverse through multiple libraries. Data Managers become 
part of the design team, and Hbraries are programmable to 
meet the needs of the design group they service. 
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COMPUTERIZED DESIGN AUTOMATION 
METHOD USING A SINGLE LOGICAL PFVL 
PARADIGM 

COPYRIGHT NOTICE AND AUTHORIZAHON 

Hiis patent document contains material which is subject 
to copyright protection. 

(C) Copyright International Business Machines Coqjora- 
tion 1995, 1996 (Unpublished). All rights reserved. 
Note to US Government Users — Documentation 
related to restricted rights — Use, duplication, or disclo- 
sure is subject to restrictions set forth in any applicable 
GSA ADP Schedule Contract with International Busi- 
ness Machines Corporation. 
The owner, Intemational Business Machines Corporation, 
has no objection to the facsimile reproduction by any one of 
.the .patent, disclosure, as it appears in the Patent and Trade- 
mark Office patent files or records of any country, but 
otherwise reserves all rights whatsoever. 

HELD OF THE INVENTION 

Hiis invention is related to a Data Management Contiol 
System and Methods for Conoputerized Design Automation 
(CDA) ^plications, and particularly to methods useful fior 
concurrent engineering in connection with the design, devel- 
opment and manufacturing of complex electronic machines 
such as computer systems and their complex electronic 
parts. 

GLOSSARY OF TERMS 

While dictionary meaning;^ are also implied by certain 
terms used here, the following glossary of some terms may 
be useful. 

AFS Andrew File System — ^File Management System 
developed by Transarc Inc. and used on Unix/AIX 
Networks. 

API Application Program(ming) Interface. 

ASC Accredited Standards CbmmiUee (ANSI) 

BOM Bill of Materials 

QM Computer Integrated Manufacturing 

CR Control Repository 

CRC Cyclic Redundancy Check 

CLSI Compiler VHDL Analyzer developed by Compass 
Design Systems 

DCS Design Control System. Our Design Control System 
incorporates Data Management System Processes, 
including interactive data management systems which 
supply processes which may be applicable in general 
data management systems, such as a process manager, 
a promotion manager, a lock manager, a release 
manager, and aggregation manager and the other pro- 
cesses we describe herein as part of a Computer Inte- 
grated Design Control System and, where die context 
applies. Data Management System, is a Data Manage- 
ment System functioning within an overall integrated 
design control system. 

DILP Designer Initiated Library Process 

DM Data Manager or Data Management 

DMCU Data Management Control Utilities 

DMS Data Management System 

DR Data Repository 

EC Engineering Change 

EDA Electronic Design Automation 
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GUI Graphical User Interface 
POM Product Data Management 
PIM Product Information Management 
5 PN Part Number 

RAS Random Access Storage 
sim static inline memory 

tape-out Delivery of a coherent set of design data to 
manufacmring. Also known as Release Internal Tape 
10 (RTT) within IBM. 

TDM the Qidence Team Design Manager (most currently 
Version 4.4) 

VHDL Very High-level Design Language — ^A high level 
language comprised of standards supported by IEEE 
and the EDA industry. The language is widely used in 
the electronics and computer industry and by the mili- 
tary as an alternative to Verilog and ADA, other high 
level computer coding languages, 

20 BACKGROUND OF THE INVENTION 

As Data Management systems grow more complex, they 
have more users interacting with them, and issues such as 
performance, data integrity, workload management, batch 

25 processing, efficiency and continuous availability need to be 
solved. Many systems on the market today can only handle 
small numbers of users simultaneously, offer little or no 
expansion capabilities and frequently require manual inter- 
vention to process data through the system. In addition, the 

30 mechanisms for maintaining data integrity, ownership, and 
file management are either limited in capability or are unable 
to prevent loss of data and/or collisions under certain 
conditions. With the growing presence of distributed 
computing, and the increased need for sharing large amounts 

35 of data across an enterprise, a solution is required to address 
these problems for a conoputer integrated design control 
system for concurrent engineering and other applications. 

In the article entitled "Beyond EDA (electronic design 
automation)**, an example of one kind of computerized 

40 design automation (CDA), published in Electronic Business 
Vbl.l9, No.6 June 1993 P42-46, 48, it was noted that while 
biUioQS of dollars have been spent over the past (then and 
still last) five years for electronic design automation systems 
(EDA) and software to help companies cut their design 

45 cycle, a huge gulf remains between design and manufactur- 
ing. To eliminate the gulf and thus truly comply with the 
commandments, companies are extending the concept of 
concurrent engineering to enterprise wide computing. The 
concept, which calls for integrating all the disciplines from 

50 design to manufacturing is becoming the business model of 
the 199Qs. Achieving an enterprise wide vision requires 
tying together existing systems and programs and managing 
the data that flows among them. Software that makes that 
linkage possible is largely in the class known by two names: 

55 product data management (PDM) or product information 
management (PIM). Mr. Robinson, the author, described the 
experiences of several companies with PIM and PDM, in 
particular Sheipa and Cadence. 

The design of complex parts, such as integrated circuits, 

60 computers, or other complex machines in a complete manu- 
facturing operation like IBM's requires computer capability, 
with oomputei^ capable of processing multiple tasks, and 
allowing concurrent data access by multiple users. The IBM 
System 390 operating system known as Multiple Virtual 

65 Storage (MVS) allows such ibia^ as relational database 
management methods, such as the TIME system described 
by U.S. Pat. No. 5333,316, to be used to reduce design time. 
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The TIME system is used within IBM for the purposes 
described in the patent during circuit design. However, these 
prior efforts treated design as directed to an entity and did 
not achieve the efficiencies provided by the system detailed 
in our description of our invention, which also can run under 5 
MVS, but also under other operating systems. Our detailed 
description of our invention will illustrate that we have 
furthered the objects of the invention of U.S. Pat. No. 
5333^16 by increasing the flexibility of a number of circuit 
designers who may concurrently work on designing the 
same integrated circuit chip and reducing the interference 
between chip designers. With the prior system, a user (a 
person, processor or program capable of using data in a 
relational database) was given a private copy of the master 
table. Alteration of a row in the user tablis was not auto- 
matically updated in the master table, because a lock mecba- 
nism prevented the row update, but that was an great 
improvement at the time, because no longer did multiple 
users have to'wait for'copying of a table, each time data firom 
a user needed to be updated. This row locking and treatment 
of data has become widespread in the relational database 20 
field, and it has been enabled for use with multiple instances 
of a platform even on Unix machines today. We should note 
that also in the MVS art, there have been proposed various 
library systems, e.g. those represented by U.S. Pat. Nos. 
5,333,312 and 5^33,315 and others which relate to IBM's 25 
Image Object Distribution Manager in the ImagePhis prod- 
uct line of IBM, and IBM's Office Vision are examples of 
systems enabling control of a source document while allow- 
ing access by multiple users. Implementation of these pat- 
ented ideas enable synchronous and asynchronous copying 
of a document into a folder in a target library. These methods 
provide for check out of a document and its placement in a 
target library while locking the document in the source 
library to prevent changes while the checked out document 
is out. But these steps are only some of the many things that 
are needed to bring a product to a release state. Bringing a 
product to a release state is an object of the current devel- 
opments relating to design control in a manu&cturing set- 
ting. 

Concurrent engineering is required among many engi- 
neers working in parallel and at different locations world- 40 
wide. Furthermore, as noted by Oliver Tegel in "Integrating 
human knowledge into the product development process" as 
published in the Proceedings of the AS ME Database 
Symposium, Engineering Data Management: Integrating the 
Engineering Enterprise ASME Database Symposium 1994. 45 
ASCE, New York, N.Y., USA. p 93-100, specialists who are 
not working directly together are often needed for solving 
the demanding tasks that arise during the development of 
today's advanced products. During product development, 
assistance is required from other departments sudi as 50 
manufacturing, operations scheduling, etc. Even the vendors 
and customers should be integrated into the product devel- 
opment process to guarantee the product devebped will be 
accepted in the market. 

There ts a need for integrators/coordinatorsAnodel build- 55 
ers and die designers to work together to create a next 
release. Information from different people in different forms 
must be collected aiming at a final good design. A problem 
occurring during product development is, bow to know 
which people to contact for what kind of information, but 60 
that is only one. During all of the process concurrent 
engineering, particularly for the needs of complex very large 
scaled integrated system design, needs to keep everything in 
order and on track, while allowing people to woik on many 
different aspects of the project at the same time with 65 
differing authorizations of control from anywhere at any- 
time. 



For the purpose of the following discussion, need to say 
that we call our system a "Computer Integrated Design 
Control System and Methorf* because it encompasses the 
ability to integrate CIM, EDA, PDM and PIM and because 
it has the modularity making it possible to fulfill these needs 
in a concurrent engineering environment particularly useful 
to the design of complex very large scaled integrated sys- 
tems as employed in a computer sjrstcm itself. ITic making 
of these systems is a worldwide task requiring the work of 
many engineers, whether they be employed by the manu- 
facturer or by a vendor, working in parallel on many 
complete parts or circuits which are sub-parts of these parts. 
So as part of our development, we reviewed the situation and 
foimd that no-one that we have found is able to approach the 
creation of "Computer Integrated Design Control System" 
like ours or employ the methods needed for our environ- 
ment. Our methods are modular and fulfill specific 
functions, and yet make it possible to. integrate them, within 
a complete "Computer Integrated Design Control System". 

A patent literature review, especially one done with ret- 
rospective hindsight after understanding our own system and 
method of using our "Computer Integrated Design Control 
System" will show, among certainly others, aspects of DMS 
systems which somewhat approach some aspect of our own 
design, but are lacking in important respects. For instance, 
after review of our detailed description, one will come to 
appreciate that in modem data processing systems the need 
often arises (as we provide) to aggregate disparate data 
objects into a cohesive collection. These data objects may 
reside at various levels of completion, spanning multiple 
versions and/or repositories in a hierarchical, multi-tiered 
data management system. Additionally, these data aggrega- 
tions may need to be hierarchical themselves, in order to 
enable the creation of large groupings of data with varying 
levels of granularity for the data included therein. In such a 
data management system, the end-useis of the data aggre- 
gates are not necessarily the "owners" of all or any of the 
data objects comprising the data aggregate, but they have a 
need to manage the particular collection. Management of a 
data aggregation may include creating the aggregation, 
adding or deleting data objects, moving the aggregation 
through a hierarchical, multi -tiered data management system 
and tracking the status of the data aggregation in real-time 
while maintaining the coherence of the data aggregation. 
Creation of a data aggregation or the addition of a data 
object to an existing data aggregate may need to be accom- 
plished within the data management system or via data 
objects imported into the data management system through 
application program interfaces for the data management 
system. 

With such a focus, when one reviews the art, one will 
certainly find, currently, data management systems which 
provide means for grouping components of a data system to 
facilitate the retrieval thereof. However, these data manage- 
ment systems are insufficient and lacking because they fail 
to address the above-referenced need for grouping disparate 
data items, just to mention one a^ect of our own develop- 
ments. 

Another example, U.S. Pat. No. 5,201,047 to Maki et al. 
(issued Apr. 6, 1993) teaches an attribute based classification 
and retrieval system wherein it is unnecessary to implement 
an artificial code for indexing classifications. The patent 
teaches a method for defining unique, user-determined 
attributes for storing data which are capable of being readily 
augmented without necessitating the modification of the 
imderlying query used for retrieval thereof- However, the 
Maki et al. patent requires that the data items being grouped 
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share at least one common attribute to enable tbe grouping, pieces of di^arate systems which don't interact, and even 

and therefore fails to address the problems of managing data such a combination would not achieve our desirable results, 

aggregates formed from disparate and unrelated data For the purposes of comparison, after our own description 

objects. of our environment, our "Computer Integrated Design Con- 
Other data management systems address the creation of 5 trol System", we wiU discuss the features of the Cadence 

dataaggregatescoupled toparticularprocessesimplemented ^eam Design Manager Version 4.4 and ViewU)gic's View- 

in the data system. For example, U.S. Pat No. 5^21,605 to ^^^^ Sections which compare with and refer to the 

Chapman et al. (issued Jun. 14, 1994) teaches the creation of ^^^oos of our own preferred "Computer Integrated Design 

a Bill of Resources table which represents the resources System" as set forth at the beginnmg of our detailed 
consumed in the performance of a given process. Attribute 10 description of our mvention. This comparison wi^l show the 

tables for the given resources arc utiUzed to determine shortcomings of ihcsc pnor systems, as well as some 

whether an additional processes which will consume some changes which could be made to these pnor systems to allow 

or aU of the resources of a given process can be initiated. The ^ improve performance in our concurrent engmeenng 

patent to Chapman et al, requires that each process to be enviromnent by takmg advantage of aspects of our own 
initiated have a particular Bill of Resources aggregate asso- is development as alternative embodmients of our mvention. 

ciated therewith. This tightty coupled construct does not Historically many attempts have been made to collect or 

permit the creation of data aggregates not related to a group objects together in order to solve typical data man- 

"partiMar'^iDCCK^ impleii^^^ the data management agpment problems. These problems may-include identifying- 

system. Furthermore, since a process must be contemplated ^ ^^e files used to create a model, or grouping files 
in order to create a Bill of Resources table, Chapman et al. 20 together to facilitate transport through a medium. The intent 

do not permit the creation of aggregates without forcknowl- » ^^suzhy to ensure the group remains together for a sped- 

edge of the process that requires the resource. Thus, in a period of time. 

manner similar to that described for Maki et al.. Chapman et The most common method in use today is to create a 

al. require that a relationsh^ between the elements exist listing of files commonly referred to as a Bill of Materials, 
prior to the formation of the Bill of Resources grouping. 25 Many commercial products permit creation of such a BOM, 

Also, unrelated DMS systems are known which are used these BOM are static list BOM. For example, is one of 

for hardware implementations which enable related data in membcis of the BOM disappears or gpts changed, the 

a computer memory, storage or I/O subsystem to be physi- ^J^r f unaware that the ongmal data set used to create the 

cally grouped in proximity to other such data so as to ^ °o 

improve hardware performance, appUcation performance, ^° We have created a new process which we call an Aggre- 

and/or to solve memory management issues are known. For g^tion Manager which can be used in Bill of Materials 

example, U.S. Pat. No. 5,418,949 to Suzuki (issued May 23, applications but which overcomes prior disadvantages and 

1995) teaches a file storage management system for a also one which can be used in our Computer Integrated 

database whidi achieves a high level of clustering on a given Design Control System. 

page and teaches loading related data from a secondary SUMMARY OF THE INVENTION 

storage unit at high speed. The patent uses map files includ- - . ... _^ m _ ♦u ^ «^ 

. fTfji:- . t ^ c In accordance with our mvention we provide a method for 

mg a metamap file for dcfinmg page to page rclabons of * • j j ♦ * • 

j.r™ , t5 computerized design automation, comprising, accessing a 

data. These hardware implementations are not related to the xji jj.i- ^ \ c . , 

viaia. ±iiv-3^ liQiwvToiv uxi^ivuiviitauv/ii^ oiv uwi. .vj databasc management system for managing a plu- 

prcsent mvention, as they mvolve the management of the i% • . j • / i ♦ ■ a ^ 
. , . . ^ J *! L- . .1. XL 40 rahty of projects as a design control system, organizmg data 

physical contents of a data object rather than the manage- -. J . -.rj. j j .i 

wwu u« wi. " " J f repository for each project for data records and a control 

ment of aggregations of data objects as we perform the % . . ^ ^ 

, ^ ^ . . *^ ^ , ^ . repository compnsing a common access mterface and one or 

methods of our present mvention. It is contemplated, j /u j * i % • 

. ... r* L-i i_ more databases, said control repository commumcating with 

however. th.t such known h«dware techniques may be P^^^ J ^^^^j^ J^^^ 

miplemented m a system compnsing the agg^gation m«^. ^ ^^.^ repositories of said data management 

agement feauiies disclosed herem, thereby further augment- ♦ i ♦ *u u i i * c S 

. * . 11 . «= . control system through a plurality of managers, each man- 

mg the overall system efficiency. / ■ c a j -^u- *u' 

^ ' ^ ager performmg a unique function. And withm this envi- 

During our development process we have viewed the ronment we provide application support whereby users 

development of others. Even the best of the EDA(electromc combine selected ones of said managers for supporting an 

design automation) design houses don't have an integrated computerized design automation appUcation environment 

approach like we have developed. suitable for multiple users of a user community located at 

For the purposes of this background, we will discuss some workstations anywhere in the world accessible via a 

of the various approaches abeady used specifically viewing network, an intranet, extranet or via the internet, 

them in light of our own separate developments which we Thus it will be seen that our invention relates to storing, 
will further elaborate in our detailed description of our 55 moving, retrieving and managing data in a system com- 

invention which follows later in this specification. prised of one or more shared public libraries interacting with 

Id the field of EDA, there are today two preeminent one or more private lil>raries arrapged in a client server 
vendors of development software. Cadence Desigp Systems, environment. Elements of the system may exist on a homog- 
Inc. and ^ewLogic, Inc. Of course there are others, but enous computer platform, or the elements may be scattered 
these two companies may have a greater range of capabUity 60 across multiple platfonns in a heterogeneous environment, 
than the others. Also, there are in house systems, such as The Design Control System incorporates processes for hard- 
IBM's ProFrame which we think is unsuitable for use. It will ware design, software development, manufacturing, inven- 
not function well as a stand-alone DM point tool for inte- tory tracking, or any related field which necessitates execu- 
gration into a foreign framework. But even the largest tion of repetitive tasks against multiple iterations of data in 
microelectronic systems are customers of the two named 6S a quality controlled environment and our invention enables 
vendors which we will compare. Today, a DCS, it will be sharing of h1)raries in this environment for concurrent engi- 
seen, without our invention, would require fitting together neering. 
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We provide with these appicalions various systems, me ih- agemenl system and third party tools. Thus we further 

ods and processes for data management particularly suited provide that each component is labeled as an input or an 

for use with a data management system having shared output of its associated anchor. Thus we provide that each 

libraries for concurrent engineering firom locations any- one component may be an anchor to another different model, 

where in the world, along with an management systems 5 and when such a component is an anchor to another different 

allowing promotion of multiple design BOMs through van- model, said different model consists of said said such 

ous levels of development, while handing multiple component acting as one anchor and further consisting of 

problems, multiple releases and multiple parts control for one or more associated components each of which is a data 

computer integrated design control within our data manage- object in said data management system. In accordance with 

ment system for releases, and file and database management. lO our invention our components components can belong to 

Our invention provides a design control system usable in level and version of any library in said data management 

a concurrent engineering process which can cooperate in a system and our components are not restricted to the same 

distributed environment worldwide to enable a design to be library, level and version as the anchor, and our components 

processed with many concurrent engineering people and comprise multiple data types, including data generated 

processes. The system we employ uses a a data management ^oois of said data management system and third party 

control program tangibly embodying a program of instruc- tooh. 

tions executable by a supporting machine environment for Each of our components has field identifiers like those of 

pelfbrming^ inetfidd'ste^^^ aggregation manager of a oiir adchor and eacH'component is aliso' labeled as an^input 

data management system having a library organization or an ou^ut of its associated anchor. Each one component 

which receives a request of a user initiated from said ^0 may be an anchor to still another different model, with eadi 

displaced client screen and fulfills the request by providing component being labeled as an input or output in relation to 

result via our data management system's aggregation man- its anchor file. All components of a model are either static 

ager. and thus docs not move through said data management 

Otir invention provides an improved way to make or system but is tracked by the system or dynamic and moves 

import a model, and provides a dynamic way to track the ^ through said data management system with its associated 

model during its course through its design phase. We provide model as part of an action of promoting a model when a 

a way to track the BOM. model is promoted, a dynamic member being labeled as an 

Id order to make a common model, we display for jnputoranoutput with respect to its assoa^ated anchor, while 

creation of a model one or more control screen sections as 3^ I'oth anchors and components may be labeled as stauc. 

part of a control panel input screen allowing creation of a With these facilities, concurrent engineering is enhanced, 

model by interactive user activity, by importing a file listing, ^^^^ creation of a model, thereafter, our system provides 

by searching of a library of files in said data management continuously tracking the created model while allowing a 

system and importing a located file, or by use of an appli- user to modify it by adding components, deleting 

cation program interface with a collection of model man- 35 components, changing the status or deleting said created 

agementutilitiesutilities. Our sections of said control screen model, and allowing promotion of a model in our data 

panel include: processing system through the libraries of our data process- 

(a) a display screen section displaying a first field repre- ™S system. 

senting the name of an anchor name field of a model which Tills, along with many other changes have been made as 

is identical to the name of a data object which is serving as 40 detailed in the description of our invention which follows, 

a named anchor; ^^^^ DESCRIPTION OF THE DRAWINGS 

(b) a di^lay screen section displaymg a second field 

representing a library v^iiere said named anchor resides; The subject matter which is regarded as the invention is 

(c) a display screen section displaying a third field rep- ticulariy pointed out and distinctly claimed in the con- 
resenting the type of date object identified by said anchor « eluding portion of the specificaUon. The mvenUon, however, 
jjjj^jg. both as to organization and method of practice, together with 

^jv' - , ^ , , further objects and advantages thereof, may best be under- 

(d) a display screen section displaying a fourth field reference to ihe following description taken in 
IS * connecdon with the accompanying drawings in which: 

so FIG. 1 illustrates a prior art system in which our present 

(e) a display screen secUon displaying a fifth field repre- (em can operate by changes made to the database and 
senting user entries for the leve of said named anchor for ^^j^, accordance with our detailed 
use by a user or a third party tool for creating, modifying or descriotion 

deleting an aggregate collection of data objects, encompass- r j u ^ . 

ing those u^ for items that are identified, tabulated, „ FIG. 2 illustrates our preferred embodmient's data entry, 

tracked, validated and invalidated, and promoted, as are bills ^ ^l^rates our preferred Design Contiol System 

of materials, by said data management system; and Level Structure; 

(0 a display screen section displaying a sixth field rep- , ^^^ J illustrates our preferred Design Control System 

resenting user entries for the status of said named anchor. Structure with Versions; 

Our model thus consists of one anchor and one or more 60 ^}^^ ^ (Alustraied in p^ts HG. & and 5b) illustrates our 

associated components, each of which is a data object in said P^^^^^^ ^^^"^"^ ^^^^^ Examples; 

data management system. This means that our components. I ^ illustrates our preferred Mechanism for Update 

can belong to any level and version of any library in said I Locks; 

data management system and said componente are not \ FIG. 7 (illustrated in parts FIG. 7a and 7b) illustrates our 

restricted to the same library, level and version as the anchor, 65 preferred Promotion Mechanism; 

and our components can and do c omprise multiple data FIG. 8 (illustrated in parts FIG, 8a and Sb) illustrates our 

types, including data generated by tools of said data man- preferred Design Fix Management and EC Control; 
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FIG. 9 illustrates our preferred DCS Using an Actor/ 
Object Eavironmeot; and 

FIG. 10 illustrates our preferred Example of Location 
Independent Data Tracking; 

FIGS. 11, llfl-lld describes the QRFILDEL Process. 

FIG. 12 illustrates the overall diagram of the Promote 
Process. 

FIG. 13 depicts a data entry screen for initiating a 
Promote. 

FIGS. 14a thru 14f describes the algorithm for Promote 
Foreground Processing. 

FIG. 15a thru ISe describes the algorithm for Promote 
Background Processing. 

FIG. 16 illustrates the Overall Structure of our Design 
Control System's Data Management facilities. 
_FIG. 17 illustrates.^the .Control Repository. 

HG. 18 illustrates the Data Repository. 

FIG. 19 illustrates the Inverted Tree Library Structure 

HG. 20 illustrates the Library Structure File. 

DETAILED DESCRIPTION OF THE 
INVENTION 

Overview (Section 1.0) 

In order to introduce our Design Control System we will 
describe it as it can be applied to development of complex 
circuit design aixl development projects such as micropro- 
cessor design projects. The implementation of our Design 
Control System can be implemented in a variety of ways 
using many computing platforms as is suitable for a con- 
current engineering project While we will describe our 
preferred embodiment, it should be recognized that with this 
teaching all or part of our exact implementation of user 
interfaces, methods, features, properties, characteristics and 
attributes may vary depending on the platform chosen and 
the surrounding design system. All of these variances will 
nevertheless employ those routines which implement our 
processes and which meet our requirements. 

Platform (Section 1.1) 

The Design Control System (DCS) in our preferred 
embodiment, even though it can be implemented with other 
platforms, runs on a network of RS/6000's (workstation 
class "personal" computers) with an AIX operating system 
arranged in a Client-Server fashion. Each client and server 
in our preferred embodiment, is able to implement cross 
platform code via interpretation, and thus can implement 
programs written in cross platform languages like Java and 
VRML, In such situations, Java can interact with VRML by 
describing extension modes, acting as scripts, and describing 
the actions and interactions of VRML objects. 

While more powerful situations are contemplated, the 
system can be installed in a prior art system, like that 
described in U.S. Pat No, 5^33,312. Thus, as we show in 
FIG. 1, the prior art system of the earlier patent, can be 
employed in this application, by providing the system with 
new programs. However, such a system, as illustrated by 
FIG. 1 will be a data processing system 8, which may 
include a plurality of networks, such as Local Area Net- 
works (LAN), 10 and 32, each of which preferably includes 
a phirality of individual computers 12 and 30 (which may be 
RS/6000 workstations or powerful PCs such as the ffiM 
Aptiva's. As common in sudi data processing systems, each 
computer may be coupled to a storage device 14 and/or a 
printer/output device 16. One or more such storage devices 
14 may be utihzed, to store applications or resource objects 
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which may be periodically accessed by a user within the data 
processing system 8. As we have said the system is provides 
with a repository, illustrated by main frame/server computer 
18, which may be coupled to Uie Local Area Network 10 by 

5 means of communications links 22, and also to storage 
devices 20 which serve as remote storage for the LAN 10. 
Similarly, the LAN 10 may be coupled via communications 
hnks 24 supporting TCP/IP through a subsystem control 
unit/communications controller 26 and communications link 
34 to a gateway server 28. Gateway server 28 is preferably 
an individual computer which serves to link the LAN 32 to 
LAN 10. The main system can be located anywhere in the 
world, and remotely from the various servers and clients 
coupled to it over communications links. The main system 
can accommodate hundreds of users making requests to the 

15 centralized repository (a large server 18, such as one of 
IBM's S/390 platforms or IBM's RISC System/6000 Scal- 
able POWERparallel Systems (SP) platform for design 
control information: (AIX,'Sy390; RS/6000, RISC System/ 
6000 and Scalable POWERparallel Systems are trademarks 

20 of International Business Machines Corporation, Armonk, 
N.Y) 

Since this repository 18 (a large server and its associated 
storage) is critical to the entire design team, it has the ability 
to remain available if a single server fails. In addition, the 

25 data is secured via a backup or archiving mechanism per- 
formed on a regular basis. Our DCS has important perfor- 
mance characteristics. It can handle a distributed computing 
environment with data being transmitted over LANs and 
telephone lines linkiDg distant locations in real time. Users 

30 at one site experience no noticeable delays accessing data 
physically located at another site. Due to the complexity of 
the design, maximum throughput is attained by transferring 
only the control data necessary to carry out the specific task. 
For large projects design control information can be physi- 

35 cally segregated by library, version and level to minimize the 
bottleneck caused by too many users accessing the same 
physical server. In the case of the design data, the physical 
data is tracked via pointers whenever possible, so as to 
minimize the amount of file movement between servers, 

40 Although, the "ofiSdal" control information is centralized in 
one place, the DCS permits certain data to be cached locally 
on the users machine to improve performance by reducing 
traflSc to the Design Control Repository. For example, much 
of the control information for private libraries can be cached 

45 locally in order to maximize perfomiance for private library 
accesses. For public libraries, the DCS allows the user to 
take "snapshots" of a library in which the image of the 
library is refreshed locally. The user continues to work with 
his local image of the library until he deems it necessary to 

50 refresh the image. The amount of control data that is actually 
cached is dependant on the enviromnent and the actual 
implementation. Many of the performance issues arc dis- 
cussed fiu-ther in the Sections to which they pertain. 
Libraries and Design Control Repository (Section 1.2) 

55 The Design Control System has two important compo- 
nents. The Design Control Repository contains the control 
information for all components of the design. This includes 
such things as the names of all the pieces, the type of data, 
the level, the version, the owner, and any results which are 

60 deemed quality control records. These results indicate the 
''degree of goodness" of the design component and they are 
used by the DCS to make decisions regarding the type of 
actions which can be performed on a piece of data. This 
repository can be and is preferably implemented in the form 

65 of a database (relational, object oriented, etc) on using a 
flat'file system. The actual implementation is usually based 
on the environment. 



04/19/2004, EAST Version: 1.4.1 



5,9; 

11 

As we have said, and as illustrated by the machine to 
person interface depicted by FIG. 2, our program of instruc- 
tions executable by a supporting machine environment for 
performing method steps by an aggregation manager of a 
data management system having a library organization 
which receives a request of a user initiated from said 
displayed client screen as illustrated by FIG. 2 and fulfills 
the request by a providing a result wbidi provides a dynamic 
way to track a model during its course through its design 
phase via our data management system's aggregation man- 
ager. 

In order to make a common model, we display for 
creation of a model one or more control screen sections 
which provide our control information components 235, 
236, 237, 238, and 239 as part of a control panel input screen 
allowing creation of a model by interactive user activity, by 
importing a file listing providing the data of screen sections 
* 235;236;237, 238, and 239, by searching of a library of files 
in said data management Systran and importing a located file 
containing the data of screen sections 235, 236, 237, 238, 
and 239, or by use of an application program interface with 
a collection of model management utilities which provides 
the data of screen sections 235, 236, 237, 238, and 239. 
These data fields of our control screen which when created 
by a user comprise data entered in the form boxes (a form 
is a screen section entry field for representing a model) 
illustrated in FIG. 2, and when reuieved or otherwise 
obtained by the system by importing a file listing providing 
the data of screen sections, by searching of a library of files 
in said data management system and importing a located file 
containing the data of screen sections, or by use of an 
application program interface with a collection of model 
management utilities all provide the data of a control screen 
panel sections which include: 

(a) a display screen section dii^laying a first field repre- 
senting the name (235) of an anchor name field of a model 
which is identical to the name of a data object which is 
serving as a named anchor, 

(b) a display screen section displaying a second field 
representing a library (236) where said named anchor 
resides; 

(c) a display screen section displaying a third field rep- 
resenting the type (237) of data object identified by said 
anchor name; 

(d) a display screen section displaying a fourth field 
representing user entries for the version (238) of said named 

anchor; 

(e) a display screen section displaying a fifth field repre- 
senting user entries for the level (239) of said named anchor 
for use by a user or a third party tool for creating, modifying 
or deleting an aggregate collection of data objects, encom- 
passing those used for items that are identified, tabulated, 
tracked, validated and invalidated, and promoted, as are bills 
of materials, by said data management system. 

Furthermore, while, as in the other cases for entry section 
fields, the same screen does not have to, but can, di^lay an 
additional field which displays status information, libus, as 
illustrated by FIG. 2, the system provides a display screen 
section displaying a sixth field representing user entries for 
the status of said named anchor. Now each field can be 
display separately and various combinations can be made, 
but all fields are provided by and used by our system. At any 
time, the entire model schema can be diq[)layed, as it is in the 
field 240, which displays several models names, as well as 
their anchor, type, library, version, level and status (which is 
dynamically tracked by our system). 
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Our model thus consists of one anchor (with a name 235) 
and one or more associated components, each of which is a 
data object in said data management system. This means that 
our components can belong to any level and version of any 

5 library in said data management system and said compo- 
nents are not restricted to the same library, level and version 
as the anchor, and our components can and do comprise 
multiple data types, including data generated by tools of said 
data management system and third party tools. 

10 Now once a model is created or otherwise identified, it 
becomes part of our system. Indeed the second component 
is our Design Libraries. They hold the actual pieces of 
design under the control of the system. There is no limit to 
the number of libraries tmder the management of the Design 

15 Control Repository, and hierarchical designs are allowed to 
traverse through multiple libraries. The libraries arc man- 
aged by Data Managers (Librarians) who are members of the 
design team. All major facets of the libraries are program- 
mable so they can be tailored to the needs of the design 

20 group they service. Certain desigp groups require more data 
control than others, so the flexibility exists to widely vary 
the degree of data control. Libraries are categorized as 
Public or Private. Both can be shared, but the main differ- 
ence is that a private library is managed by the acmal 

25 designer. It's used to hold his daily updates and often will 
have no formal control. The DCS achieves this by defaulting 
all control information to a simple non-restrictive form. For 
example, any designer can create private libraries on their 
own. They automatically become the owner and have the 

30 right to make additional designers "backup** owners. As the 
owner they can edit, save, modify, or delete any data in their 
library. The DCS automatically establishes all the proper 
AFS and AIX permissions. Owners of private libraries 
control who can access their data with the system accom- 

35 modating the use of default "access groups" (such as AFS 
groups) so the designer doesn't have to enter the userids of 
all his team members each time he creates a new h*brary. 
Since Private Libraries are considered working areas, data 
control checks are minimized in order to maximize perfor- 

40 mance. For example, when a new data element is created, 
the DCS does not check the Control Repository to make siu-e 
the owner has the proper authorities, locks, etc.. Instead, a 
designer is permitted to work in a completely unrestricted 
fashion in his own work space. All controls are placed on 

45 public libraries. Tbe only control checking required is to 
ensure there are no data conflicts within the Private Library. 
It is acceptable for two Private Libraries to contain the same 
design data, so no checks across libraries are done. Public 
Libraries are the official project data repositories. All data 

50 delivered to external customers comes from Public Librar- 
ies. Public Libraries are overseen by Data Managers who 
configure the libraries with varying degrees of control. 
Typically the libraries are organized with a level structure 
whereby the lowest levels have the least amount control. 

55 Control gets more stringent as the levels increase, and the 
highest level denotes data released to manufacturing. Almost 
every attribute concerning data integrity is programmable by 
the Data Managpr. Through a Data Manager Utility, they 
configure the structure (the number of levels and versions, 

60 including the connections between them), the various 
authorities, the required criteria to enter each level, and the 
types of Library Controlled Processes required at each level. 
The system can handle niunerous public libraries, and each 
public library can service unlimited users. In accordance 

65 with our prefened embodiment of our DCS architecture we 
provide an Automated Library Machine (ALM). More than 
merely a repository for data, the ALM is a userid capable of 
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accepting, executing and dispatching tasks without any 
human intervention. This enables the designers to make 
requests of the ALM to promote data or run library processes 
without the need for a Data Manager to process it. 

lo order to improve throughput, the ALM can dispatch 
parallel tasks if the operating system (i.e. AFS) supports it 
and the situation allows it. 

This concepts improves efficiency, and increases security, 
since the ALM is the only user that requires writable 
permissions to the data repositories. The physical location of 
the data residing in Public Libraries is determined by the 
Data Manager. Hie DCS along with the Data Manager (and 
his alternates) are the only means of writing data into or 
removing data from these physical locations. As a means of 
safety, the Data Manager does have the ability to access and 
overwrite data in these physical locations without using the 
DCS (i.e. thru the OS). Tfais is necessary in the unlikely 
event thr'oontfor'infonnation' gets out of sync with the 
physical data, and the Data Manager has to manually com- 
plete a transaction. Physical locations are defined through 
the Data Manager Utility for setting up Public Libraries. 
More details on this are available in the Data Manager User 
Interface Section 15. 

Data Types (Section 1.3) 

Data may be identified by a filename (anchor name 235) 
and a filetynpe (236). The DCS automatically segregates aU 
data by "type**. Types are very useful to associate a piece of 
data with a tool or process. For example, UNIX/AIX uses 
extensions to qualify data such as using a ''.ps'* extension to 
denote a postscript file. The Cadence Design Management 
System uses Cell Mews to segregate the various types of 
data within a particular Cell (design component). This 
segregation is a fundamental building block to Design 
Control Systems since certain types of data require more 
design control than other types. Our DCS aUows each 
individual type to be controlled on a level and version basis 
within a library. The DCS is capable of tracking any data 
type &om any point tool, even third party vendors. 

Levels (Section 1.4) 

Each Public Library consists of q levels which are estab- 
lished by the Data Manager. The naming of the levels (239) 
are arbitrary, but each denotes a degree of quality of the 
design. Data moves into and out of levels via a "promotion" 
mechanism. There are two types of levels in the DCS, 
Engineering (or working) and Release Levels. 

FIG. 3 shows a typical level structure with 3 Engineering 
Levels denoted El, E2 and E3, two main Release Levels 
denoted Rl and R2, a Sideways Release Level SI, and a Fast 
Path Stream consisting of F21 and F22. Data can be pro- 
moted into El, F21, E3 and SI from outside of the Ubrary, 
but it can only enter R2 from E3. El, E2 and E3 are arranged 
in a serial fashion. The normal promotion path is for data to 
enter El (the least controlled level) and migrate up through 
E2, E3 and finally into R2 (the most tightly controlled level). 
The external paths into F21 and E3 are known as ^^fast paths" 
and exist to accommodate emergency updates to pieces of 
design residing at the higher levels. There are two different 
types of fast path arrangements: 
Fast Path Entry means there is no fast path level associ- 
ated with the Engineering level, just a "doorway" 
through which data can enter. Level E3 is an example 
of this where the user simply promotes data from the 
private library into E3. The DCS will run any pre- 
processes defined at E3, but any criteria that would 
normally be necessary to traverse through El and E2 is 
bypassed. 
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Fast Path Levels are staging areas where data is promoted 
into, and promoted through, in order to reach the target 
Engineering Level, There can be any number of Fast 
Path levels for any given Engineering Level. If there's 
5 more than 1, it's known as a Fast Path Stream since the 
data must migrate through all the Fast Path Levels 
before reaching the Engineering Level. E21 and F22 
constitute a stream, which could 've contained more 
than 2 levels. We have provided at least one level to 
10 provide an area where all the processing normally run 
at the El and £2 levels can be run to ensure that the fast 
path data meets all the same criteria. 
Release Levels are handled in a different manner. Rl is 
the oldest release level and it's frozen, which means its 
15 contents can't be updated any longer. It contains a static 
snapshot of a design delivered to an external customer. R2 
is now the active Release Level which is the destination of 
*any data promoted from- E3. -The Data'Managerprograms 
the connection of £1 to E2 to E3 to Rn. The DCS automati- 
20 cally freezes the previous Release Level and connects £3 to 
the new Release Level whenever the Data Manager creates 
a new one. Unlike main Release Levels, Sideways Release 
Levels are always active and there can be n Sideways Levels 
for each Release Level. Hie purpose of the Sideways Levels 
25 is to hold post tape-out iqidates such as microcode patches 
to hardware under test. Since the Release Level correspond- 
ing to that level of hardware is probably frozen, and a new 
iteration of design is propagating through the Engineering 
Levels, the only path into a Sideways level is directly from 
30 a Private Library. The Data Manager has the ability to 
reconfigure the Engineering Levels at any time based on 
these rules: 

The connections between levels can be changed at any 
time. (i.e. E-^E2->E3 can be changed to 
35 E1-*E3^E2.) 

A level can be removed as long as no data resides in that 
level. 

A level can be added at any time. 
^ The Data Manager can create a new Release Level at any 
time. Existing firozen Release Levels can be removed as long 
as no data resides in that level. A frozen level can become 
an active level again if no data resides in the current active 
Release Level. The DCS performs a ''thaw", a step which 
removes the current Release Level (R2) and connects the 
previous level (Rl) to E3. As shown in FIG. 3, the DCS 
supports the normal promotion path to £1 as well as "fast 
paths" into E2 and E3. The following minimum checks are 
performed at all entry points: 
50 The owner attempting to send data to a Public Library 
must possess the update lock. If no lock exists, the 
sender obtains the lock by default. If another user has 
the lock and the sender is a surrogate, he can obtain the 
lock (the system immediately notifies the original 
55 owner). If the sender is not a surrogate, the action is 
halted, until ownership is properly transferred. 
If the level to which the data is being promoted to has any 
entry criteria, it is checked to ensure the data passes the 
criteria. 
60 Versions (Section 1.5) 

Each public library consists of n versions which are 
defined by the Data Manager. The concept of versions exist 
to support parallel design efforts. All versions have the same 
Engineering (Working) Levels, but have different Release 
65 Levels depending on the fi^equency of tape-outs for that 
version. Data in separate versions is permitted to traverse the 
levels at independent rates. For example, if a piece of design 
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has 2 versions, 1 version may exist at El while the other 
version exists at E3. FiG. 4 is an extension of RG. 3 in 
which library structure has been expanded to show 3 
versions, VI, V2 and V3. In theory there's no limit to the 
number of versions just as there's no limit to the number of 
levels. Versions can be independent or dependent. Irxiepen- 
dent versions are isolated and must ultimately contain the 
entire set of design components. Dependent versions are 
based on previous versions (which the Data Manager speci- 
fies when creating a new version). By supporting the concept 
of dependent versions, only the incremental data necessary 
for a new design variation needs to be libraried in the new 
version. The library Search mechanism will be able to 
construct a complete design Bill of Materials by picking up 
data from both versions. 
Library Search (Section 1.6) 

Our preferred embodiment of the DCS provides support 
"for ^Library Searches"? This allows data, which'is used in 
multiple iterations of the design, to exist in only one place. 
In other words, if a design component is cbang^ only that 
component needs to be re-libraried at a lower level. A full 
mockl can still be constructed by starting the search at the 
lowest level where the component is known to exist. The 
library search mechanism wiU pick up the latest pieces at the 
lowest level, then search through ibc next highest level to 
pick up more pieces, and so on until it reaches the highest 
level where all components reside. In addition to searching 
through levels, the medianism also searches through ver- 
sions. The user provides a starting library level, version and 
either a single type or a list of types. If the version is based 
on a previous version, and all the necessary design compo- 
nents can't be located in the starting version, the mechanism 
searches the previous version based on the following two 
rules: 

1. If the search begins at an Engineering Level in one 
version, it resumes at the same Engineering Level (qo\ 
the lowest level) in the previous version. 

2. If the search begins at a Release Level (including a 
Sideways Level) in one version, it resumes at the latest 
Release Level in the previous version. This may be 
older or more recent in time than the released data in 
the current version. 

FIG. 5 shows examples of the Library Search Mechanism, 
The library search utility is available to designers. Data 
Managers and third party tools. The inter&ce is both 
command-line and menu driven to accommodate any envi- 
ronment. In addition to the required parameters of type, level 
and version, the user has the option of specifying the name 
of a data object. These additional options exist: 

Noacc 

This allows the utility to use a temporary cached copy of 
the search order information for performance reasons. 
Since this information may be obsolete, the absence of 
the option results in the actual Design Cbntrol Reposi- 
tory being accessed and the search performed from 
within it. 

File 

Write the results into an external file. 
Various Sorts 

They control the way the ou^ut is sorted and displayed. 
Nosearch 

Only list data found at the starting level. 
Fiist/All 

Indicates whether to include all existences of a particular 
design component or only the first one in the search 
order. 
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Select 

Presents a selection list of all candidates so the user can 

choose those of interest. 
Noversion 

Prevents the search from tracing back across version 

boundaries. 
Levels 

Displays the search order based on the existing level 

structure. 
Versions 

Displays the search order based on the existing version 

structure. 
Locks (Section L7) 

In order to properly control shared data, the DCS supports 
several types of locldog mechanisms. Two of the locks exist 
to control groupings of files that may comprise a model 
build.-These are known as move and overlay locks. The- user- 
can set one of these locks using a utihty which allows him 
to control the scope of the lode based on certain fields. The 
user can enter ^ecific data or a wildcard, indicating "ALL", 
for 

Name of Design Cdmponents 
Type of Design Components 
Level of Design Components 
Version of Design Components 
Library Name 

By specifying only a library name and four wildcards, the 
user is requesting that all dau in the library be locked. By 
filling in all five entries, a specific design component will be 
locked. Various degree of locking exist in between those 
extremes. 

If the information corresponds to a Bill of Materials 
(BOM) and the user wants to set the lock on the entire BOM, 
a BOM Flag will exist allowing him to specify this action. 
Regardless of how these fields are filled in, all locks will be 
set individually so they may be removed individually. A lock 
does not have to be removed the same way it was set. The 
user will also specify the type of lock, Move, Overlay, or 
Update (Ownership). The following definitions exist: 
Move Locks mean the data can't be overlaid by the same 
data at lower levels^ nor can it be promoted to a higher 
level. This provides a method for completely freezing 
an Engineering Level while a model build or large scale 
checking run is in progress. 
Overlay Locks are a subset of move locks. The data can't 
be overlaid by the same data from lower levels, but it 
can be promoted to higher levels. 
Update (Ownership) Locks are the means by which a 
designer takes ownership of a piece of data. Update 
locks are designed to prevent multiple designers from 
updating the same design component in an uncon- 
trolled way, thus resulting in data corruption or lost 
information. There are two types of Update locks, 
permanent and temporary. 
A permanent Update lock exists when the designer spe- 
cificadly requests to own a piece of data. This is done through 
a utility, and the DCS keeps track of this ownership. Other 
designers may copy and modify the data in their private 
libraries, but any attempt to promote that data into the public 
library will fail, unless the designer is a designated surrogate 
of the owner. The only way these locks are removed are by 
the owner resigning the lock or a surrogate asstmiing the 
owneisbip of the data, and the corresponding lock. A tem- 
porary Update lock exists to facilitate sharing a piece of data 
among multiple designers. The user can either request a 
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temporary Update lock in advance (i.e. when he begins 
editing the data), or he can wait until he initiates the promote 
into the public library. The DCS will first check to sec if 
anyone has a permanent Update lock, and if so, it will only 
allow the promotion to continue if the user is a designated 5 
surrogate. If nobody has a permanent Update lock, then the 
DCS will issue a temporary Update lock for the time the data 
remains "en route" to the final promote destination. Once it 
arrives safely, the temporary Update lock is removed and the 
data can be claimed for ownership by someone else. Surro- iq 
gates are "alternate" owners of data. For example, a project 
may be arranged such that each piece of design is owned by 
a primary designer, but also has a backup owner (designer) 
to take over the design during vacations, emergencies, etc.. 
In this case, the owner can tell the DCS that the backup 15 
designer should be a surrogate, thus giving him the right to 
take ownership of a design component. The surrogate can 

either use the locking utility .to^specifically-take-ownership 

prior to making any updates, or be can wait until he initiates 
a promotbn. The DCS will check to see if the design 20 
component is currently owned, and if so, check to see if the 
user is a defined surrogate. If both are true, it will give the 
user the chance to "take owTiership" and allow the promote 
to continue. The original owner would be notified that his 
surrogate has taken ownership. FIG. 6 illustrates the lock 2s 
mechanisms for Update locks. 
Bill of Materials Tracker (Section 1.8) 
The DCS has a built-in Bill of Materials (BOM) Tracker 
to facilitate tracking many design components in large 
projects. The main objective of the BOM Tracker is to group 30 
certain design components to make it easier to promote them 
through the library and track their synchronization. This is 
crucial for data sets that contain some source and some 
derived files firom that source. The following features exist 
in the BOM Tracker: 35 
It supports automatic data grouping, based on the design 
component name, with the notion of required and 
optional data types. One example might be a grouping 
which consists of a graphical symbol denoting the I/O 
of a design component, the corresponding piece of 40 
entity VHDLand the architectural VHDL. Any changes 
made to the symbol should be reflected in the entity, so 
the entity would be required. A change may also be 
made to the architecture, but it's not always necessary, 
so the architectural VHDL would be optional. When a 45 
promote is initiated to a public library, or between 
levels of a public library, the DCS checks to see 
whether a data grouping is defined for the data type 
being promoted. If so, then all required data types are 
checked to ensure they exist. In addition, any optional 50 
data types are checked for existence and they are also 
picked up. The entire grouping is promoted to the target 
level. If a required data type does not exist, the pro- 
motion fails. Automatic data groups are programmed 
into the DCS by the Data Manager. Since they are 55 
BOMs, all rules of BOM tracking, invalidation and 
promotion exist for the members of the grouping. 
BOMs are used for two main reasons. First they are used 
to group many ^nailer pieces of data into larger more 
manageable chunks to facilitate movement through the 60 
library and increase data integrity by reducing the risk 
of data getting out of sync. The other main reason is to 
track the components of a model (i.e. simulation, 
timing, noise analysis, etc.). The DCS ofieis a very 
flexible user interface for creating BOMs in order to 65 
satisfy the various scenarios. The user can manually 
create BOMs by selecting pieces of design 
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interactively, filling in search criteria and initiating a 
library search, or importing a simple text list. In 
addition, an API exists for point tools to create a BOM 
listing and pass it into the DCS. 

The power of the BOM Tracker is augmented with our 
automatic invalidation routine. Once a BOM is created, 
the DCS constantly monitors for a change to the BOM. 
If any member is overlaid or deleted, a notification is 
sent to the owner of the BOM indicating that the BOM 
is no longer valid. The owner can continue to work with 
his model, but he is aware that he's no longer using 
valid data. Even though a BOM is invalid, it can still be 
moved through the library. This accommodates the 
occasion where a piece of a model bad a relatively 
insignificant change. If the model buik!er deems it 
unnecessary to re-build the model, this feature allows 
him to continue his work and even move the BOM 
through the library. ' 

Status on BOMs is and should be accessible in two ways. 
The first is by automatic notification (e.g. e-mail) to the 
owner as soon as a BOM is invalidated. The second is 
by means of displaying the BOM either interactively or 
in report form. This listing shows the overall status of 
the BOM, and all members of the BOM with their 
individual status. 

The BOM Tracker also supports the concept of a "sup- 
port** object. This can be a design component, a piece 
of information, documentation, etc., that can be asso- 
ciated and promoted with a BOM but never causes 
BOM invahdation. 

BOMs are hierarchical in namre and a BOM can be nested 
within a larger BOM. Whenever a piece of data is 
overlaid or deleted, the DCS looks to sec if that piece 
belonged to a BOM. If so, it immediately checks to see 
if the BOM belongs to other BOMs. It recursively 
checks all BOMs it encounters imtil it's at the top of the 
hierarchy. All BOMs found will be invalidated (if they 
are currently valid) and the owners notified. 

BOMs support move and overlay locks. The user can set 
a move or overlay lock on a BOM, and the DCS will 
set individual locks on all the members. If a member is 
a BOM, all of its members will receive individual 
locks. These locks can be removed by using the main 
lock utility and specifying the top-level BOM or filling 
in the desired fields to individually reset locks. 

The DCS supports the concept of a BOM promote, which 
means tbe user can request that all the contents of the 
BOM be promoted simultaneously. This increases data 
integrity by helping to ensure a matching set of design 
data traverse through the library in sync. 

BOMs can contain members who reside at different 
levels, different versions and even different libraries. 
The DCS will only promote those members which exist 
in the current library, and reside in an Engineering 
Level below the targiet level. If a member exists in a 
different version and is also below the target level, it 
will also be promoted. 

There is separate authorizations for creating and promot- 
ing BOMs. This is set up by the Data Manager, so they 
can have complete flexibility in controlling who can 
create and move BOMs. 

Promotion Criteria and Promotion Mechanism (Section 
1.9) 

An important aspect of the DCS is that it provides a 
method for the design to traverse to different levels of 
goodness. As the design stabilizes at the higher levels, the 
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number of pieces which Deed to be moved and tracked can 
be very large. The DCS uses the cooccpt of promotion 
criteria and robust mechanisms to first determine what data 
can be promoted, then carry out the task in an expedient 
manner. The DCS supports two variations, "move" and 
"copy", promotes. In a "move" promote, data appears to the 
user like it only exists at the target level once the promote 
completes. The user is unable to access the copy that existed 
at the previous level. For example, if a design component is 
at level E2 and the user promotes it to £3, when the promote 
is finished and the user refreshes his image of the library, he 
sees the data at E3 only. In a "copy" promote, the data still 
appears at the previous level. The user can access it at either 
location. As new iterations of the same design component 
are promoted into a level, the old component is not truly 
overlaid. It is moved off to the side so it can be restored in 
an emergency. Promotion criteria usually exists in the form 
of . library process or pseudo-process results, but.in general 
it can be any condition that must be met by the tbe object(s) 
being promoted. It is defined by the Data Manager and can 
exist for any design component at any level and version. 
Certain design components don't undergo any formal check- 
ing or evaluation in the design process, so they may never 
have any promotion criteria. Other pieces may undergo the 
majority of checking so they may have lots of criteria. The 
objective of the DCS is to track actual results for each design 
component and use the promotion criteria to determine if the 
design can attain the next level of goodi^ss. When a design 
component is overlaid or deleted, all corre^nding results 
are deleted too. The DCS supports an emergency override 
mechanism wbidi allows the Data Manager to promote data 
which does not meet the criteria. Invoking an emergency 
override cause a log entry to be written indicating criteria 
has been bypassed. The Data Manager determines which 
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BOM. In this scenario, the entire algorithm would be 
executed on the BOM itself to ensure the proper authority is 
in place, it meets the promotion criteria, and any processing 
that's defined is executed. However, each member could 
bypass some of tbe checks thus saving a significant amount 
of time. If tbe user community opts for flexibility, some 
optimization can still be performed. For example, if a BOM 
contains 10 members and the mechanism calls for five 
checks on each member, there doesn't need to be 50 requests 
for information. Depending on the platform, it may be 
optimal to either make one large request for each member 
(ten total requests) and obtain all five pieces of information 
in the request. In other cases it may be optimal to initiate a 
request for a piece of information, but solicit it on behalf of 
all ten members (five total requests). Since these BOMs can 
be extremely large, the various kinds of optimizations and 
trade-ofik between flexibility and performance determine the 

exact implementation. As a convenienoe.feature, the^.DCS^ 

supports a multiple promote feature which allows the used 
to request a promote through multiple levels. For each level 
the promotion mechanism is followed as stated above. For 
example, when initiating a promote, the user can specify to 
move data from El to E3 with a single invocation. However, 
the DCS will internally break it into two separate promotes 
with the full mechanism being run for the £1 to £2 promote, 
then again for the E2 to E3 promote. 

Library Controlled Processing (Section 1.10) 
The concept of Library Controlled Processing allows 
tasks to be launched firom a public library, against one or 
more design components, with the results being recorded 
against the components. This is an automated method to 
ensure that tasks, and checks deemed critical to the level of 
design are run and not overlooked. Since some of these tasks 
could be third party tools, the actual implementation can 
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results are necessary for which types of design at each 35 vary in sophistication. In its simplest form. Library Con 
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Engineering and Release Level. These results may get 
recorded through ''library controlled" or ''external" process* 
ing. At the time the promote is initiated (whether it be 
against individual design components or BOMs), the mecha- 
nism illustrated by FIG. la and FIG. lb is invoked to 
determine what pieces should be promoted. There are three 
types of promote transactions. 

1. Promotion of an Individual Design Component 

2. Promotion of a Group of loosely-coupled Design 
Components 45 

3- Promotion of a Group of tightly-coupled Design Com- 
ponents (i.e. BOMs) 

Basically, the same mechanism is employed in all three 
cases, but cases 2 and 3 require additional optimization for 
high performance. In case 1, each step in the medianism is 50 
executed once and the promotion either succeeds or fails. 
Case 2 is initiated by a user selecting a group of objects to 
be promoted. They may or may not have any relation to each 
other. In this case some optimization is done, but each object 
is basically treated as if it were initiated as an individual 55 
promote. For example, the authority check only needs to be 
done once since the same user is requesting the promotion 
for all the objects. However, since each object can have 
unique locks, criteria, processes defined, etc., most of the 
steps need to be repeated for each object. Case 3 is the most 
complicated because the DCS offers a great deal of flexibil- 
ity. The acmal implementation is dependent on the platform 
of the DCS and the type of control mechanism in place 
(file-based, object oriented database, relational database, 
etc.). If the user community wants to eliminate flexibility in 
return for increased performance, the DCS can enforce rules 
such as no library processing allowed for members of a 



60 



65 



troUed Processing consists of tbe following constituent 
parts: 

Foreground Processing: 

This is the conduit by which the user enters any infor- 
mation required to run the tool. Menus may be pre- 
sented or the user may interact in some other way. 

Pre-processing: 

This refers to a library controlled process that is launched 
prior to the data being promoted to the target level. The 
process must finish and complete successfully, based 
on the promotion criteria of that process, if the promote 
is to continue. For example, if a pre-process is defined 
at level E2, then when the promote to E2 initiates, the 
process is launched and the promote ^suspends" until 
the process completes. Once it finishes, tbe result is 
compared against the criteria to ensure it's satisfactory. 
The promote then resumes. 

Post-Processing: 

This refers to a library controlled process that is launched 
after the data arrives at the tai^get level. The results of 
the process are used as promotion criteria to the next 
level. 

Designer Initiated Library Processes (DILP): 
This is very similar to a post process, but instead of the 
DCS latmching the process, it's manually launched by 
the designer. DILPs usually exist to retry Post- 
Processes which failed. Ibis eliminates the need for the 
user to re-promote the data just to initiate the process- 
ing. If a DILP is used to recover a failing Post-Process, 
and the DILP is successful, the good result will over- 
write the bad result firom the Post-Process. Just because 
DILPs are primarily used to recover failing Post- 
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Processes, the DCS doesn't make this a restriction. The etc.. Therefore, the DCS allows the Data Manager to specify 

Data Manager can set up DILPs as stand-alone pro- a particular machine or pool of batch machines where the 

cesses with no corresponding Post-Process. DILPs that tasks can execute. Either the task is transferred to the 

exist to recover failed Post-Processes are optional in specific machine or a request is queued up in the batch 

that they are not counted as required promotion criteria. 5 submission system. In the event that a task must run on a 

Stand-alone DILPs can be optional or mandatory, with completely different platform, the DCS provides hooks to 

mandatory DILPs being required to run successfiiUy in launch a h*brary controlled process from one platform which 

order for the data to promote to the next level. The DCS initiates a task on a different platform (i.e. a mainframe). The 

allows the Data Manager to designate which DILPs are results are rettimed back to the original Automated Library 

mandatory and which are optional. 10 Machine and processed. This Cross-Platform capability 

Level Independent fteudo Processes: allows the DCS to encompass a broad and sophisticated 

These are special types of process which are more like methodology utilizing tools on many platforms. Regardless 

process results than actual processes. They exist as a of how the process is launched, the results must ultimately 

means to record information outside of the scope of get recorded within the DCS. To accomplish this, the DCS 

results from Library Controlled Processes or External is provides an /plication Program Interface (API) through 

Data Processing. For example, suppose a Library Pro- which third party tools can communicate. When the task 

cess exists to run a layout checking program which completes, the API is used to convey the results and the 

checks "for wiring" and-ground-Tule violatioos. Ulti- pedigree information back to tte DGSrThe DGS piovides— 

mately the program will return some pass^il result, both an interactive means and a report generator to view 

such as a return code, v^ich the DCS uses as the 20 process results. FIG. 7fl and FIG. 7/> illustrate the method by 

process result. The tool may also return other useful which promotions and library controlled processing interact, 

information which the designer wants to save, such as External Data Processing (Section 1.11) 

the number of wires or cells in the design. I^udo External Data Control is very similar to the Designer 

processes provide a repository for this kind of data. Initiated Library Process in that the user launches a task 

Like DILPs, these can be used as mandatory criteria for 25 against some design component(s). However, unlike DILPs 

promotion, or they can be optional and used solely for which require that the design components be under the 

information. They can even serve as status indicators control of a Public Library, this tj^e of processing is done 

for design components progressing through a lengthy on data in Private Libraries and designer's work spaces, 

process at a particular level. The concept of level External processing is the mechanism whereby the DCS 

independence means the checking program could be 30 captures the results of the process along with pedigree 

run at the E2 level, but the pseudo process results can information concerning the iapul data, output data and any 

be stored at E3. In short, the DCS allows a pseudo necessary software support or execution code. This pedigree 

process to be defined at any level, and it can be set by information is stored along with the design component for 

a process nmning at the same level, any other level or which the designer initiated the process. When the designer 

completely outside of the h*brary. The DCS provides an 35 promotes that component at a later time, the DCS checks the 

API for setting level independent pseudo processes. pedigree information to ensure nothing has changed. It then 

The API can be used by designers. Data Managers or checks to see if the extenoal processing matches any of the 

third party took, and employs a "process search" defined library processes which are required for the promote, 

similar to a hbrary search. This means the API allows If so, and the external processing results meet the criteria, 

the user to specify the name of the process, the data 40 the library process results are set (as if the library process 

type, level and version. The DCS will use this as a just ran automatically) and the promote proceeds. If no 

starting level and search for all matching pseudo pro- matching process can be found, the external results continue 

cesses defined at or above this level by following the to be saved with the design component as they process may 

same library search mechanism as in FIG. 5. A flag also match that at a later level. The concept of External Data 

exists to disable the search and set the result for the 45 Processing exists to increase productivity by allowing the 

process specified at that level and version. designer to save, and later apply, results obtained during the 

Any number of any type of process can be defined by the normal course of design mles checking to the "oflBcial" 

Data Manager for a given data type at a particular level and results the DCS uses to determine the level of goodness, 

version. In addition, processes can be chained together in Overall data integrity can easily be breached if a proper 

independent or dependent sequences. In a dependent 50 mechanism for calculating pedigree information is not 

sequence, eadi process must complete successfully before implemented For this reason it's imperative for the DCS to 

the next process in the chain can initiate. For example, when ensure that all the proper input, output and software data are 

compiling VHDL, the entity must always be compiled prior included in the pedigree information. External Data Pro- 

to the architecture. Thus two compiles could exist as a cessing occurs in two phases. In the first phase, the designer 

dependent sequence where the entity is compiled, the resuh 55 runs some tool or process and if the resiilts are acceptable, 

checked, and if successful, the architecture is compiled. In he nms a utility to designate the data for external processing, 

an independent chain, the first process initiates, and when it The role of the utility is to create the Pedigree information 

completes, the next process runs regardless of the outcome which contains a listing of the input and output data, the 

of the first process. Processes can also execute using input results, and some type of date identification code for each 

data other than the object used to initiate the promotion. 60 member of the Pedigree and the Pedigree itself. A simple 

Using the VHDL compile example, the actual object being identification code is a cyclic redundancy check. The utility 

promoted could be a simulation BOM which contains that can be independent of or incorporated into the actual diird 

entity and architecture VHDL. The DCS provides a robust party tool. The second phase consists of h^brarying the data 

system for the Data Manager to define the processes which and the results. The designer invokes a fecial form of a 

should be run, and the type of data they should nm on. 65 promote which first does the following: 

Certain library controlled processes require special 1. Check the data identification code (i.e. CRC) of all 

resources such as large machines, extra memory capacity, members in the Pedigree 
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2. Check the data identification code of the Pedigree itself. 

These 2 steps are designed to ensure the same data used 
to generate the result is indeed being libraried. The identi- 
fication code of the Pedigree ensures that the contents of the 
Pedigree weren't manually altered. From this point on, the 
normal promotion mechanism in FIG. 7a and FIG. 7b is 
followed with one exception. The boxes where Foreground, 
Pre and Post Processing occur are all bypassed. Rather than 
simply checking existing results to see if they meet criteria, 
the DCS makes a list of all Pre-processes for the target level 
and Post processes for the previous level. It then checks the 
Pedigree information for evidence that equivalent piooesses 
were run and achieved acceptable results. If any piooesses 
exist in the DCS for which no corre^jooding Pedigree 
results exist, or any Pedigree result docs not meet the 
prescribed criteria, the promote fails. 

Authorities (Section 1.12) 

-The- DCS permits the-Data-^Manager to -establish- a wide 
variety of authorities which gives him great flexibility io 
managing the library. Each type of authority can be defined 
very loosely (the user is authorized for all design 
components, at all levels, in all ver^ons) to very tightly (the 
user is authorized on an individual design component basis). 
The utility for granting authorities works in one of two 
modes: 

In one mode the Data Manager is offered a screen io 
which he can fill in the design component name, type, 
level, version, user ids, and the type of authority. For 
any field, except for the user ids, he can default it to 
"ALL". 

In the other mode an authority profile can be called up and 
executed. An authority profile allows the Data Manager 
to pre-define the types of authorities for a given type of 
job. For example, profiles may exist for Designer, 
Technical Leader, Model Builder, etc.. This informa- 
tion is contained in an editable ASC file in which the 
Data Manager defines the kinds of authority to varying 
degrees of restriction. Once the profiles are created, the 
Data Manager uses this mode to either add/delete users 
to/from the profile and process the changes within the 
DCS. 

Authorities exist for the following tasks: 
Setting Locks (Move, Overlay, Update, ALL) 
Promoting design ccmpooents and/or BOMs into levels 

(Engineering Levels, Release Level. 
Creating BOMs 
Initiating Library Processes 
Setting Pseudo Process Results 
Data Manager GUI User Interface (Section 1.13) 
The DCS contains a robust Data Manager interface which 
is used to "program" the library. It*s configured as a series 
of sub-menus arranged under higher level menus. Each 
sub-menu has fields to fill in and may employ Predefined 
Function (PF) keys for additional features. Graphical ele- 
ments such as cyclic fields, radio buttons, scrollable 
windows, etc.. may be used to further enhance usability. 
Utilities exist to: 
Define the library properties 

The user is afforded a means to enter the path of the 
repository where the data resides, the userid of the Data 
Manager and any alternates, the userids of any Auto- 
mated Library Machines, and whether the library is 
under £)esign Fix or Part Number and EC control. If the 
hlirary is under any type of control, additional entries 
are made for the data types which should be tracked by 
Part Number, the data types which should be tracked by 
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Design Fix number, the EC control level, and a field for 
a generic problem fix number. For any ALMs, the DCS 
will automatically add the proper authorities (including 
operating system authorities) to permit the ALM to 
5 store data and record results. 

Define the structure (levels, versions and their 
interconnections). 
This is the means by which the Data Manager adds and 
deletes levels and versions. It also enables him to 
defined the intercoimections of the levels, and the 
dependance of versions on other versions. A minimum 
interface consists of one screen for level structure and 
one for version structure. The level structure screen 
displays the current structure. 
1^ Define the types of data which will be under library 
control. 

For all data types known to the DCS, this enables the Data 
Manager to select those managed in this particular 
library. The screen displays aU known data types in the 
^ system with a flag indicating whether it's being tracked 
by this library. Each data type also has a field for an 
alternate storage location. This solves the problem 
caused by certain data types that can be very large. 
Therefore, problems may arise in trying to store these 
data types along with the all the other types in a 
particular level. By specifying an alternate storage 
location, these large data types can be further segre- 
gated. 

^Manage Library Controlled Processes 
^^or each level, the Data Manager can add, modify or 
delete processes. For each process information is 
required about the type of machine it can run on, any 
necessary aigumentSy the result criteria, disposition 
3^ instructions for the output, whether it's dependent on 
another process, and whether it should be deferred. The 
DCS provides Process Specific Boilerplates which can 
be used to manage process con^gurations for an entire 
project. Necessary and required information for each 
^ process can be programmed into the DCS, so when a 
Data Manager attempts to define that process to his 
library, some of the fields appear with default data 
already filled in. H ejan override any of the da ta. 
The information for each process c^^bs,£a tered/edi ted 
indi vidually on a menu containing all thTabovc lTeWor a 
utility exists to loaa "process groups^^ which are pfe-de fiued 
libra ry controlled proce sses. The Data Manager simply 
selects a process group and attaches it to the appropriate data 
type, level and version. The process groups are ASC based 
files which contain the necessary process information in a 
prescribed format. They can be created using any ASC 
editor. 

Set up authorities. 

See the previous Section 1.12 for details. 
55 Define automatic data groupings (Subset of BOM 
Tracking) 

This enables the Data Manager to define a data group 
which consists of a master object and member objects. 
\ Each member object can be required or optional. For 

60 each master object entered, the user mtist enter a list of 
member objects with their required/optional flag. In 
addition, an Erase-To-Level flag exists which deter- 
mines the outcome of the following scenario: a data 
group, comprised of optional members, exists at a 

65 level. The same data group, without some of the 
optional members, exists at the next lowest level Upon 
promotion of the lower level data group, the DCS will 
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either erase the members of the upper level data group 
or leave them, depending on the Erase-To-Level flag. 
By leaving them in place, it allows members of newer 
data groups to join with members of older data groups. 

Design Fix Tracking (Section 1.14) 
'^V One of the most powerful aspects of our DCS is provided 
by the process used to track fixes to design problems. This 
is accomplished by tightiy or loosely coupling the DCS to a 
problem management database. Typically, a problem is 
found and entered in the problem tracking database. Once 
the design components are identified which require 
updating, the DCS is used to attach the problem number to 
those design components. Ideally this ^ould be done prior 
to the design components entering the library, but it can be 
done as part of the pfomote. It's often redundant to track all 
design compcments with problem numbers, so the DCS can 
be pFogranuned to only enforce De^go Fix Trackixig on 
certain data types. Whenever a promote is initiated, the DCS 
checks to see if the library is in Desigp Fix Traddng mode 
(which means some data types require Fix problem numbers 
to enter the library), and looks to see if any of the data types 20 
included in the promotion are being tracked For those that 
are, a screen displays all known problem fix numbers for that 
design component. The user can select an existing one or add 
a new one to the list. At this time, the DCS will check to see 
if the EC control level is being crossed (or bypassed via a 
fast path promote). If so, it will attempt to associate the 
problem fix number to an EC identifier. If it can't automati- 
cally determine this association, the user is prompted to 
enter the EC identifier for the selected problem fix number. 

If the designer chooses to do the association in advance, 
a utility exists which allows him to enter a problem fix 
number or choose a default number. The status is immedi- 
ately reflected as "working^. Once the promotion is initiated 
the status will switch to ''Ubraried". The DCS offers utilities 
to view or print reports showing which design components 
exist for a problem or which problems are fixed by a design 
component The report generator allows the user to enter the 
problem number and see which design components are 
associated to it Or the design component can be ^ecified to 
see which problems it fixes. Finally, and EC identifira- can be 
specified and all problem numbers and design components 
associated with the EC can be displayed. 

Part Number/EC Cbntrol(Section 1.15) 

In addition to tracking design fixes, the DCS can track the 
design by part number and/or EC. For projects which assign 
part numbers to various design components, the DCS pro- 
vides utilities to generate and associate these part numbers 
to the design components. In addition, the DCS supports 
Engineering Changes where successive tape-outs are 
assigned an EC identifier. All design components participat- 
ing in an EC are associated with the EC icfentifier. Since part 
numbers are assigned to specific design components, the 
DCS uses the links between components design fixes and 
EC's to track the association of part numbers to ECs. The 
DCS uses the concept of a PN/EC control level to permit the 
Data Manager to determine at which level PNs and Design 
Problem numbers get associated with EC numbers. As 
design components cross this level, the DCS checks to see 
whether a problem niunber or PN exists for the component. 
If so, and the system is able to determine which EC that 
number is associated with, it automatically connects the 
component to the EC. Otherwise, if no EC information can 
be foiind, the user is asked to enter it. The rules for Design 
Fix and EC control are as follows: 

One EC can contain multiple Design Fixes; 

Any single Design Fix # (number) can only be associated 
with a single EC; 
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One design component can have many Design Fix 
numbers, but they must all belong to the same EC; and 

Variations of a design component can exist in multiple 
ECs, but each must have a unique set of Design Fixes. 

FIG. Sa illustrates a legal example. It shows two EC's 
where the first contains two design fixes and the second 
contains a single design fix. There are three design 
components, of which the one denoted AO is associated with 
Design Fix #1 and Design Fix 4i2. Design component Al is 
a different variation of design component AO The example 
shows how the two versions of design component A must 
belong to separate ECs. In FIG. Sb the rules have been 
violated since design component Al is associated with 
Design Fix #2 which belongs to EC #1. The DCS detects this 
condition and alerts the user to either move Design Fix #2 
over to EC #2, or detach design component Al from Design 
Fix #2. In addition to tracking all the part nimiber and EC 
information the DCS is capable of generating a variety of 
reports including one listing all the part numbers for a given 
EC. This report can be sent to manufacturing in advance so 
the foundry can manage their resources. 

RAS and Security (Section 1.16) 

The DCS is designed in such a manner that provides 
maximum security for the control data. None of this data is 
present in simple ASC files residing in a writable repository. 
All updates to this information must be made through the 
proper utilities by authorized people. Libraried data only 
exists in repositories where the Data Managers or owners of 
the data have write permission. This prevents other users 
from modifying another designer's data outside of the DCS. 
Nearly continuous availability is achieved by implementing 
the DCS in the following manner: 

If the primary DCS server fails, the system can be brought 
up on another server with minimal human intervention, 
Tlie physical locations of all Kbraries are determined by 
the Data Manager which permits the data to be strate- 
gically located throughout the network to improve 
availability. 

Multiple paths exist to request information from the 
Control Repository. They provide alternate routes in the 
event of network or router problems. 

Archiving and backing up data is accomplished with the 
followiag features: 

The Design Control Repository can be archived onto tape 
or backed up to another repository by the Data Manager 
as often as deemed necessary. In the event of 
corruption, this back up copy can be restored into the 
primary repository. 

All libraries can be archived to tape or backed up to 
alternate repositories defined by the Data Manager as 
often as deemed appropriate. 

The DCS provides a utility which checks to see if a 
backed-up or archived copy of the Design Control 
Rq)ository is in sync with a backed up or archived copy 
of a library. During the archiving procedure, the system 
assigns unique identification codes (i.e. CRC codes) to 
each data object These codes are used during the 
recovery to ensure the data was not tampered with 
while dormant on the back-up repository. 

The system provides a method for restoring individual 
data objects from backed-up or archived repositories in 
the event the data object is deleted firom the active 
library. 

GUI User Interface (Section 1.17) 

The User Interface consists of all the menus, dialog boxes, 
and screens by which the desigoeis interact with the DCS. 
They all have the following characteristics in common: 
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They are user firiendly with convenient on-line help. 
They share a common look and feel to make it easy for the 

user to find common features. 
When something fails or the user makes an entry error, the 

system clearly indicates the error with an English 

description of the problem, and suggestions on bow to 

fix it. 

A command line interface exists to perform any operation 
that can be done through the graphical user interface. 

Various designer utilities exist to: 

InitiatejTOnaGtfi^requcsts. The minimum interface 
requires the user to enter the_ name of a de sign com- 
ponent or sel ect from a l ist, enter the level ^-oin which 
to begin'the promote, the target level where the pro- 
mote should terminate, a flag indicating whether it's a 
BOM promote, and the version. 

Send results from ,Extemal Data Processes to„.a .h"brary. 
This utility allows the user to - enter the name of a 
Pedigree and the target level and version to which the 
Pedigree information should gp. 

Set up and manage a private library. The utility has fields 
where the user can specify the name of the Ubrary (if 
one is to be created), the library path where the reposi- 
tory will reside, the userids of the owners, and either the 
userids or authoris^ation groups of those who can access 
it. Hiese properties can be called up for modification at 
any time. Whenever the owner or access fields are 
altered, the DCS automatically updates the authority 
records within the Design Control Repository as well as 
the operating system (i.e. AFS) permissions of the 
directory where the library resides. 

Cre ate and monitor a Bill of Materials . Tlie utility offers 
two modes of operation. In the first, the user identifies 
the Bill of Materials, and enters the naines of all design 
components to be added as members. This_ same utilit y 
will display-.an«-exist ing_information for a BOM, so 
mc n^grs^an,bcjaQdified or deleted . For each member, 
the" user musi! indicate whether it's an input, output or 
support member. For an existing BOM, a function 
exists to revalidate all members, but this can only be 
done by. the BOM owner. Tbe second mode builds the 
BOM by reading all the information from an ASC text 
file written in a prescribed format. This mode can be 
used by deMgners,JiataJ^anagers, aad^lhirdjparty 
took. Regardless of how the BOM is created, a newly 
created BOM will result in the valid flags being set for 
all members. The user who creates the BOM using the 
first mode i s automatically the owne r, whereas the input 
file used for the second mode c ontains the own er 
i nformatio n. 

View process and pscudo prooess-results. The user.speci- 
fies t he design com poncnt..data,typc._l evel a nd_version. 
He can spcci^the exact proc^s.Qr^o.bi ain a lis t of all 
processes. For each process, the j iisplay _shows the 
resultfif.itexists>,-th e.date and time it was set .Jiow-it 
wasjs«t.(hl)rary_controlled process, external process, or 
manually) and the criteria. These results can only be 
chang^ by the Data Manager. 

Associate design problem numbers to design components. 
The designer uses this to pre-associate problem fix 
numbers to design components before they are pro- 
moted into the library. This way technical leaders and 
other designers can determine if a particular problem is 
being woriced on. The interface requires the user to 
identify the component by name and type. Since it's not 
io the public library yet, it has no level or version. The 
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user must also supply the problem fix number. The 
DCS automatically assigns the 'Svorking" status to it. 
Later, when the designer wants to promote the 
component, the problem fix nmnber will appear on the 
5 selection list, and after the promote completes, the 
status will change to "h*braried". The DCS allows the 
Data Manager to define a generic problem number 
which designers may select to associate with miscel- 
laneous design changes that have no corresponding 
JO design problem, 
vl^ WWW/Intemet Access (Section 1.18) 

The DCS provides a mechanism which p ermits acc ess to 
aU process and pseudo process results through the^orld 
Wide Web. Key quality control indicators can be exported 
out of the DCS into an accessible format by users on the 
WWW. Usually these results would exist in a secure reposi- 
tory which could only be accessed by WWW users who are 
working on the project. This same mechanism can. be. used . 
for network access in general, including the extranets, 
intranets, and the internet. In addition to accessing 
information, the ALMs can receive special e-mail requests 
from users to perform these tasks: 
Generate various status reports on topics such" as PN-EC 
and Design Fix Traddng, Process & l^udo Process 
Results, or BOM information. The DCS would gener- 
ate the report on the fly and return it to the user's 
Internet or e-mail address, 
if the user has the proper authority, he can submit e-mail 
requests to add pseudo-process information into the 
DCS. The contents of the mail would contain a spe- 
cifically formatted command which the DCS can inter- 
pret to set the appropriate results. This could be used by 
people remotely connected to a project (such as the 
chip foundry) to send status information directly to the 
35 DCS. 

The DCS permits an authorized user to send commands 
through the Internet Common Gateway Interface (CGI) 
to query information from the DCS or invoke Designer 
Initiated Library Processes (DILPs). 
40 Actors & Objects (Section 1,19) 
\^ In the event of a project where a single large design team 
or multiple smaller ones, require their data to reside in a 
single repository, the potential exists for a performance 
bottlenedc in the Automated Library Machine. The DCS 
45 offers a feature called Actors & Objects to combat this. 
Actors & Objects allow the Data Ma nager to define an 
altern ate st ructure in which designers tasks arc dispatchedlb 
a p ool of AjHomHteS' Libraiy- Machines (Actors). No design 
data i sstore_d on any of t hem; the¥.oierelY_e xecute the tas ks 
50 then s^ ^ the resul ts and data into the Design C ontrol 
Rep^itory (UbjectJTThe Data Manager can control the 
types of jobs each Actor is allowed to p erform by creat ing 
ActorXi^ls. These lists contain informatioa^wnich the DCS 
uses to determine which ALM to route a particular job to. 
55 FIG. 9 shows an Actor/Object environment with four Actors. 
Jobs involving the data type of layout and timing arc 
segregated to ALM4. All remaining work is sent to ALMs 1 
through 3. The DCS determines which to use based on an 
mechanism which tries to find either a free ALM or choose 
60 one that may be able to spawn a parallel process (assuming 
the operating system supports it). 
Importing and Tracking Data (Section 1.20) 
Internally the DCS tracks all data by component name, 
data type, level, version, hbrary and most importantly a file 
65 reference (fileref) number. These six attributes give every 
piece of data in the system a unique identity. In a private 
library, all data is tagged with a DCS identifier as part of the 
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fileDame, but tte identifier may or may not be unique. This the locations for every level of each version. In addition, if 

is because private libraries don't have a concept of levels, he has specific data types that he wishes to further segregate, 

versions or file references. They arc merely working areas he can specify a location for them. Finally, the DCS supports 

for the designer, and only require the data to be identified by a feature called Automatic Component Grouping in which 

name and type. The system permits the designers to have 5 all data types for a given component name will automati- 

muhiple copies of a design component by using iteration ^ally be located in a subdirectory off of the level directory, 

numbers to distinguish between recent and older data. pjc iq jUustrates a portion of a hbrary directory structure 

However, even though die concepts don't apply, the DCS ^^^^^ ^ granularity. LIB_DIR is the 

still assembles an Identifier and tags the data. There axe two ^ ^ ^^^^ ^^^^^ ^^^^ ^ 

methods by which a piece of data can appear into a pnvate ^g^egated by version where version 1 data resides in the 

subdirectory VERSl. At this point the diagram ilhistrates 

1. The designer creates the daU from within the pnvate examples of further segregation. In the VERSl direc- 
library using some tool (Schematic editor, text editor, schematics and behaviors which comprise 
circuit simulator). level El and E2 for all 3 design components. Although they 

2. The data is created by some tool completely outside of js arc physically mixed together, their unique identifiers allow 
the private Ubrary, but the designer wishes to import it the DCS and users to tell them apart. The diagram shows the 
into the hbrary, circuit layouts to be further segregated by data type. So they 

In either case, the tool (or user) chooses the filename. By.. ■ - j^side in subdirectory TYPE_J^YOUT Once data reaches 

default, this is the design component name. In tlie first case, level E3, it is segregated by level and type. LEV_E3 

the designer will be asked to specify the data type either 20 contains all the schematics and behaviors for the E3 level, 

prior to, or during invocation of the tool. In the second case, but the layouts reside in the TYPE_LAYOUT directory 

the user will be prompted for the data type during the import. under LEV_^ The final example shows data segregated 

In both cases of a data type entry requirement the DCS will only by level with no regard to type. This is seen in the 

automatically default the version, level and file reference release level repository LEVARI By offering this kind of 

number in order to assemble a uniform identifier code. This 25 flexibility, the DCS permits the Data Manager to group the 

code will be appended to the design component name and data in the most advantageous way. In addition, the Data 

will become the new name of the object. Upon promotioo Manager could invoke Automatic Component Grouping, 

from a private library into a public library, the DCS will ^jch would result in further subdirectories under VERSl, 

automatically assign a real file reference nuoiber to the LEVIES and LEV_Jll to segregate the pieces by compo- 

object. Based on the destination version, and Level, the DCS 30 Qent name. 

will assemble a new identifier and rename the object accord- ^ Note: This is unnecessary in the TYTE_LAYOUT direc- 

ingly. The file reference number remains the same for the life ^ tories since the only difference between the objects is the 

of the object. As the object traverses through the levels of the component name. In orderj Qjx>ost performan ce, every time 

library, the level is the only piece of the identifier that a structuc aL chant^e is madelo a l i brary which invo lves 

changes. In addition, the DCS maintains the same identifier 35 rep^tQiie§, the DCS automatica lly generates a master cr oss 

information internally. This is considered the official trade- rclcr Sacebetween library/leycl/vcrsiQ iiAyp_e_aDd physical 

ing information and is always updated first during a prbmp- location. This table is used by mechanisms such^'as the 

tion or installation of a new object into a public library. The libr ary search engin e to locate data without requiring exten- 

object renaming is done afterwards. Appending the identifier sive querying of the Design Cbntrol Repository. It also 

to the object name serves two purposes: 40 enables Ubrary searches to occur in the event the Design 

It increases data security by providing a way for the DCS Control Repository is unavailable. 

to check data integrity during promotions. The infor- Preferred Embodiment for Managing Shared libararies 

matioa contained internally must match the external (2.0) 

identifier at the start of a promote. A mismatch signifies The present embodiment provides a controlled environ- 
possible tampering of the data outside of the DCS, and 45 ment for the acquisition, movement, disposition and removal 
^ the Data Manager is alerted to the mismatch. of data from a Data Management System. The embodiment 
It provides an alternate way for a user or another tool is described from the perspective of an overall algorithm 
(sudi as the Hbrary search mechanism) to ascertain the which manages data Libraries. This encompasses not only 
ver sion, level, and data^ type of an ob ject simply by the storage management issues but the necessary interaction 
looking at it. This contributes to the^ availability by 50 with a centralized Data Control Repository, 
providing* a means to locate and access data even if the Our embodiment covers a broad array of implementations 
Design Control Repository is imavailable (i.e. server ranging from a system whereby the user constantly interacts 
down). with the Data Control Repository to acquire ownership. 
One major advantage to this tracking scheme is it's deposit or move up through the system described in the 
independent of the physical location of the data. The DCS ss preferred embodiment which incorporates Automated 
permits the Data Manager to establish as many repositories Library Machines (ALM) with a sophisticated file move- 
as he needs down to any level of granularity. For example, ment algorithm. 

all data for a library could reside in one physical directory, The Library Management algorithm serves as the inter- 

the data could be segregated by version only, or there could face between the user and the Data Management system for 

be separate directories for each type of data. This level of 60 routine data control functions. Our preferred embodiment 

flexibility allows the Data Manager to optimize the library to interacts with the Lock and Authority Manager to permit an 

a given environment For example, he can define his reposi- environment which allows multiple users to possess own- 

tories in such a way that the data which moves most often ership in a data object, but ensures only one owner is 

is located on a single volume on his fastest server. Data updating an individual instance at any given time. A Check 

which never moves (i.e. Release Level data) can be located 65 Out utility is provided for the user to request ownership to 

on slow servers or spread out over multiple servers. As the a piece of data, transfer ownership, or take ownership if they 

Data Manager defines his library structure, he can specify are an authorized surrogate of the current owner. Likewise, 
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a utility exists to perform data deletion in a safe and 
controlled manner by ensuring only authorized Data Man- 
agers or valid data owners delete their own data without 
jeopardizing any other data. 

An integral part of Library Management is establishment 
of private and public libraries. Often these public Hbraries 
are shared by many users which can create data integrity 
exposures if data is not properly stored into and moved 
through a public library, llie overall algorithm manages the 
movement of the data between the actual physical locations 
specified under the established library structure. Since our 
embodiment permits data to reside across difi^erent computer 
platforms, the algorithm contains functions for handling 
cross-platform data transfeis. Although our Library Man- 
agpment algorithm only requires a simple promotion algo- 
rithm in order to function, the present embodiment reveals 
a highly sophisticated File Movement Algorithm. 

Lightly • loaded Data Management Systems can usually""] 

support execution of the above Library Management fuoc- I 
tions in the client's environment where the user calls upon 
the Dau Control Repository to initiate the function, and the 
repository immediately invokes the appropriate algorithm or 
utility. However, in large enterprises, this can lead to unna- 
ceptable performance degradation as many users simulta- 
neously access the repository. Therefore, our Library Man- 
agement algorithm is capable of supporting Automated 
Library Machines arranged in a variety of configurations to 
optimize performance. The use of Al^fs also permit Auto- 
mated Library Processing to occur. The UbraryJVIanager 
incorpo rates routines for properly instalh'n] ^ anv_ outp ut 5o 
created b y an Automated Lib rary ftooess into the DMS. 

Finally, the Library Manager provides instant notification 
to t he.user for any service rendered. T his occurs whether the 
task is executed in the user's environment or remotely on an 
Automated Library Machine. In the event a task fails to 35 
complete, error messages explain the problem. Successful 
operations also result in notification thus ensuring tisers 
possess situational awareness of their data at all times. \ 

Our preferred embodiment describes a File Movement 
Algorithm which interfaces with other Managers in the 40 
overall Data Management System. This provides a great 
degree of data security while offering a plethora of auto- 
mated features. The (Amotion Algorithm interacts with the 
Authority and Lock Managers to ensure that users transfer 
data that they own from a private library into a public shared 45 
library. Furthermore, only authorized users may promote the 
.^ata through the various hT^rary levels. 

Upon initiatinfi a_pro mote_rcqu cst, the algorithm com- 
pares any recorded process results ag ainst pre-defined pr o- 
modong^iteria t^ ensure t fajiL g^ data - ^lS'meete^a-qu'alT ^ 50 
standardmay b e elevated to the^ n(M{t level, 'llie prbmotio ^ 
algorithm offers a flexible means of^romoting large vol- 
umes of data including features wh ich handle he tero^neous 
tapes of data from.d ifferent levels and versions within t he 
sainejeguest. Interaction with the Aggregation Manager 55 
allows fast and efficient Bill of Material (BOM) promotes. 

The promotion algorithm also works in conjunction with 
the Problem Fix and Release Manager to apply problem fix 
trackiog, incremental change, part number and release con- 
trol to any desired piece of data moving through the Data 60 
Management System. This includes interaction with the user 
to gather the appropriate information at promotion time as 
well as backgpround checking to safeguard against data 
integrity violattons such as a single part being associated 
with two different releases. 65 

For environments such as preferred embodiment, which 
incorporate Automated Library Machines, our promotioo 



algorithm permits the user to precheck a work request 
interactively prior to the request being sent to the ALM. This 
feature ensures the work request will complete successfully 
by running all the same checks which are normally run by 
5 the ALM prior to data movement. Since our embodiment 
permits the user to request a promote through midtiple levels 
with a single invocation, this pre-qualification feature can 
greatly improve productivity. 

Id order to maximize throughput of large data volimies, 
10 our Libraty ^ anage m^ nt Algorithm employs Automated 
Library Machines to act as indepeodent agents for the use r 
community. These AEMslje service machines which use a 
virt ual queue to_ acc ept work-requests from .users and- per- 
fonn.Lib cary or non-Library functions. The ALMs interface 
directly with the Dat^ ^ntrol R;;p(^itory through dedica ted 
high speed ports in the Ctornrnuiiicatl on Manager, 'ihcv :an 
cxisfoh clients, servers and on diftereni computer platforms. 
Our preferred embodiment describes'three^basic configura- * * 
tions which permit the ALMs to perf orm any of the serv ices 
requested by the Library M anager a lgorithm. The basic 
configuration is'khown'as alZbnventional'system where a 
single ALM acc epts al l work req uests and , handles all 
ser vices for^lHTDbrac ^ Slanage r, including any Automated 
Library Processing. The second configuration is Remote 
Execution Machines which is an extension of the Conven- 
tional system. Here, a single ALM receives all work requests 
from the user, and processes all promotion, installation, 
movement, and removal of data. However, additional ALMs 
may exist to perform Automated Library Processing. The 
ALMs interact with the Library Manager, Communication 
Manager and Promotion Algorithm to dispatch any desired 
library processing to a Remote Execution Machine, which 
executes the task and returns the results to t he master ALM . 
The most powerful configuration is known Actot/Objects 
and this arrangement employs a pool of ALMs which serve 
as general purpose machines. They can perform any desired 
Library Management function, including Automated Library 
Processing. They can even interface with Remote Execution 
Madiines to provide an eovirorunent with both general 
purpose machines and dedicated service machines. Each 
A LM can be pr o gramna ed by the Data Manaefii. to definethe 
type of work requests it can process. This arrangement even 
includes a special Di^atcher ALM whose sole purpose is to 
dispatch user work requests to the next available Actor 
machine. 

Automated Library Machines are special purpose Auto- 
Reader sendee machines which means they are capable of 
performing virtually any software task that can be invoked 
from a command line. These tasks can be completely 
independent of the Data Management System which permits 
an ALM to play multiple roles in a business environment. It 
can literally be processing a Data Management request one 
minute, and formatting a word processing docimient for 
printing the next minute. The underlying AutoReader 
mechanism incorporates features to enable automatic recov- 
ery in the event of a system crash. The Library Manager 
fiirther enhances this by adding automatic retry of aborted 
library operations due to system problems. 
File Promotion Process 

The present embodiment incorporates a robust process for 
promoting data from a private h*brary into a shared public 
library as well as moving data through a shared public 
library. Although it's especially suited to interact with Auto- 
mated Library Machines and the other algorithms described 
in the other sections of the Preferred embodiment, this 
process does not require any of those elements to be present 
in the Data Management System (DMS). 
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Id order to track data properly, our embodiment provides 
a conduit for data to enter^ aod travel through, the DMS ia 
a safe and controlled manner. This ensures that all data is 
subjected to the proper checks regardless of the point of 
origin or final destination. The preferred embodiment 
dqsicts the overall flow of the promote, or data transfer, in 

no. 12. 

TTie flow begins with Step 22101 in FIG. 12 in which the 
iiser is presented with the Pro motion Scree n. FIG, 13 ^ows 
this screen, which perm its the userlo~enter information 
about the file(s) they wislTto proxiess: Promotion can entail 
transferring data from the user's private library to a public 
librasx or moving data within a public library. 

Uming our attention to FIG. 13 we see the promotion 
screen which consists of data entry fields 22201 through 
ny9f^ 22208. A single screen is used tojeitheg-Eul^ a^file fro m a 

priv ate library into the DMS ft r ^"ift^^ ^ ^ ^'^ from one level 
of the DMS to another. The type of action isBetermined by 

* •* — thcTisersuppBeCTInfonnation: ' 

The preferred embodiment presents the user screen in a 
graphical environment where the user engages pull down 
menus, pop-up menus, drop-down lists, radio buttons, push 
buttons, fill-in fields, and mouse interaction. It should be 
noted, however, that all functions discussed fiurther in the 
preferred embodiment can be implemented using simple text 
screens, or more advanced data entry systems such as touch 25 
screens, voice commands or 3-D graphics. The preferred 
embodiment depicts the method most conducive to the 
Motif™, Windows'™, and OS/2™ application environ- 
ments. 

^ Field 22201 holds the name of the file to be promoted. If 30 
^ a single file is being promoted, the name is typed in directly. 
If the user desires a selection list, it is automatically invoked 
by simply leaving the field blank and completing the remain- 
der of the form. Upon hitting Enter, a library search would 
be employed to obtain a selection list of files. The third 35 
method is to promote a group of files via a text-based list, 
edited in advance, in a prescribed format. This is covered 
below in the explanation of user options. 

Fields 22202 and 22203 allow the user to enter the 
Version and Library File Type respectively. In the preferred 
embodiment a promotion is not permitted across versions 
nor can a file type change as a result of a promote. 

Fields 22204 and 22205 convey the Source Library and 
Level information. In the case of a Put, the Source Library 
can be any vaUd private library in the DMS. The Level 
would default to User, but a valid entry level, name can be 
entered. Field 22204 can also be the name of a public b*brary. 
In this case, field 22205 would contain the starting level for 
the Promote. Each field has a "smart" drop down menu 
button associated with it The Ubrary button next to field 
22204 displays a list of all public libraries in the DMS plus 
all private libraries owned by the user. The button next to 
field 22203 displays all valid levels for the Library entered 
in field 22204. 

Fields 22206 through 22208 are almost identical to fields 55 
22204 thru 22205, represent the Destination information. 
Field 22206 is the destination library which is frequently the 
name of a public library. As with field 22204, the drop down 
menu button next to field 22206 displays all libraries in the 
DMS. However, our embodiment also permits a private 60 
library owned by the user to be a valid entry. In this case, 
fields 22207 and 22208 default to User, but can be changed 
to the valid level names, and none of the options at the 
bottom of the screen apply. The resulting operation would be 
a simple file copy from the source private library to the 65 
destination private library, with the file being named accord- 
ing to the Destination Level information. 



Returning to the general case, if field 22206 contains a 
public library then the user would fill in the destination level 
in field 22207. Once filled in, field 22208 automatically 
takes on the same value. In the case of a simple Put, field 
22207 represents the final destination aod is equivalent to 
the Destination Entry Level in field 22208. For a Put with 
Promote, field 22207 represents the destination level while 
field 22208 denotes the doorway through which the file 
should enter the DMS. Finally, in the case of a Promote, field 

22207 again represents the Destination Level and field 

22208 is ignored. 
Turning our attention to the lower portion of the screen, 

we see two sets of push buttons. The first set, 22209, 
represent user options that pertain to any type of Put or 
15 Promote. Any number of these options can be invoked and 
they are defined as folbws: 
^a List The list of files to be processed will be read from 
"a text based file.'The lise'r is presented with'a'^dialog bbx*' 
requesting the name of the file. The names of the files 
will be read from this fist, but all other information will 
be taken from fields 22202 through 22210. 
Foreground Checking Pre-checks the data using the same 
checks that will take place during the background 
portion of the promotion. This allows the user to test the 
promote and ensure everything will work before the 
request is submitted to the DMS. 
\^a Copy is normally active for most environments. It 
enables the DMS to use a file copy operation as the 
preferred method for transferring data from the source 
to the destination. In certain environments, this may not 
be possible or desirable, so deselecting this option 
forces the data to be "sent" from the source to the 
destination. 

Reset Update Lock is the means by which the user 
informs the DMS to remove any existing Update Lock 
from the file(s) and leave them in an unowned state at 
the completion of the promote. 
High Priority Tells the DMS to process this request next 
assuming it's the only high priority item in the queue. 
If there are multiple requests with this priority, they are 
processed in FIFO order. 
Override Process Farms Allows the user to add or modify 
the parameter passed to an underlying library process. 
The last set of buttons is set 22210 which represent 
options only available dtuing a Promote. This is because 
these options only pertain to data already under control of a 
DMS. Any number of them can be selected and they arc: 
BOM Promote Indicates the user wants the Bill of Mate- 
rials associated with the file entered in field 22201 to be 
promoted. If the file doesn't have a BOM associated 
with it, the promote will fail. 
Anchor Only Indicates to the DMS to only promote the 
anchor file of the BOM associated with the file entered 
in field 22201, but leave the members at their current 
locations. 

Retain Source is usually "ofiP* which enables the DMS to 
move the file from the source location to the destina- 
tion. However, in certain environments it may be 
desirable to leave a copy of the file at the source 
location after the promote is completed, so this option 
exists for this purpose. 
Returning to the overall fiowchart in FIG. 12, information 
entered in Step 22101 is now passed to Step 22102, Fore- 
ground Processing. The detailed algorithm for processing 
promotion requests in the foregroimd is described in FIGS. 
14a thru 14/ It begins with Step 22311 of FIG. 14a, Parse 
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Here all the information entered in Step 22101 is 
checked for validity. The following cases arc examined: 
If the Source and Destination Libraries are private 
hl}raries, then the Source and Destination Levels are 
allowed to be any combination of User and valid public 
levels. The user must have edit authority to the Desti- 
aatioo private library. This results in a simple file copy 
with the name being adjusted according to the Desti- 
nation level field. 
If the Source Library is a private library and the Desti- 
nation Library is public, then the following conditions 
must be met- 

1. If the Source Level is User then the Destination 
Entry Level must be a valid entry point. The Desti- 
nation Level must be the same or higher. 

2. If the Source Level is a valid entry point, then the 
Destination Entry Level must be identical. The Des- 
tination Level can be the same or higher. 

" ' If the Destination and'Destination Entry Levels are the 
same, this cla^ ges as a simpl e put. If the Destination Level 
is higherylt^sVoombined Put with Promote.'* 
If the Source Library is a valid public library, and the level 
is a valid level, then the Destination Library must be the 
sa me as the Source Library and the level must b e higher 
than th Vjource^ LeveL These conmtions 'signify a 
Promote In this case the Destination Entry Level is 
ignored. 

Any other combinations of those fields is considered an 
error condition and the promote terminates. In addition, the 
options are examined to set various flags which will be used 
to determine branching later in the algorithm. 

Step 22312, Input. Files follows Step 22311. Here, FIG.' 
13, entry field 22371, Name is examined for three possible 
responses. The simplest- case is the name of a single file 
which implies only this file is to be promoted. Second, is a 
blank or some other keyword in which the user request s a 
library sear ch of all files of the specified Library File Type 
starting at the ^cified SourocXihraiy, LevcTand'Yeraon. 
If any of these fields are invalid or missing , the user is 
prompted to enter the information. The standard Library 
Searchmajqa ger is invoked to perform this _task. At the 
coc^lellon oi the search, the user is presented with a 
selection list of all files found. One or mo re files can b e 
selected for pro motion. The third possibility is that tfie 
ViaList user option'in button field 22379 of FIG. 13 has been 
selected. This indicates that the user wants the foreground 
process to extract the names of the files from a text file. The 
user is prompted for the name of the file which lists the 
names of the files to process. All other information, besides 
the file name, is taken from the main screen. 

Once the input file(s) are determined, the algorithm enters 
the File Loop in Step 22314. For the simple case of a single 
file being promoted, this loop is only exercised once. In the 
cases where a selection list or text file was used to provide 
a list of data to promote, all Steps between 22313 and 22347 
are executed for each file. 

Step 22315 asks the question "is this a Put or Promote?" 
Hie answer to this question determines which way the 
program must branch. A Put refers to data entering a publi c 
library fro m a private library^ wherea s a Promote refers to 
Bkia Ifl6ving mrough a public hl^rary. Our embodiment 
permits a Put followed by a Promote in the same request, but 
for purposes of resolving Step 22315, that request is treated 
like a simple Put. All Promotes continue to Step 22326 in 
FIG. 14c while Puts branch to Step 22316, Fig Info in FIG. 
14b. 

In Step 22316 of FIG. 146, the program requests any 
AutomatlcJiIc Jjroup_relative to the file being pr omoted . 
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This information includes a fla g indicatin g_wheiheiL-the 
candi date file is the master file of a fl kigm iip, and if sn, the 
lisTof Library File Types associated with that file group. By 
definition, all members of a file group share the same file 
name, library, version and level. 

Step 22317 reviews the information returned in Step 
22316 to see if a File Group Exists If so, the program 
continues with Step 22318. Otherwise, it branches to Step 
22321. Steps 22318-22320 pertain to processing file groups. 
In Step 22318 the program checks for the existence of any 
Required Members of the File Group. These are denoted in 
the information returned in Step 22316. If a required mem- 
ber can't be found in the user's private library, an error 
message is issued and the promote is terminated. If an 
optional member doesn't exist, a warning is issued to the 
user, but the promotion continues. 

Step 22319 examines the Check Option whose flag was 
set in Step 22311. If it's true, then- the- locks on the all- 
existing subordinate files are examined, in Step 22320, Fig 
20 Locks, to ensure the user either owns the Update lock or is 
a surrogate for the owner. In addition, it ensures no other 
type of lock exists which would prevent the Pat. Such an 
example would be an Overlay lock at the entry level. If the 
user is not the owner, our Lock Manager will Update Locks. 
25 In our preferred embodiment, our embodiment maintains 
absolute data integrity by adhering to the foUowiog rule. The 
Foreground Check option, available to the user on the 
promotion screen in FIG. 13 only pertains to the foreground 
processing of the promote. It is ignored in the background, 
30 where fiill checking is done at all times. The option serves 
merely as a performance enhancement which allows the user 
to submit promotion requests with minimal checking. The 
advantage of the Check option is that an error free fore- 
ground session practically guarantees a successful promote 
in the background. However, depending on the environment 
and the implementation, the trade-off may be lengthy pro- 
cessing time on "the client machine. For these situations, our 
embodiment offers the user the option of bypassing a series 
of foregrotmd checks and "taking their chances" on the 
promote processing successfully in the background 

Steps 22321 and 22323 can be processed in either order, 
and they are used as decision points for Steps 22322 and 
22324 respectively. In Step 22321, the program inspects the 
Fix Management information for the package. If the package 
is under Single Fix Mode or Engineering Change Mode, 
then the LPT FM, or Library File Type Fix Management, 
flag is examined for the LFT being processed. If the flag is 
on. Step 22322 is invoked, otherwise the program proceeds 
to Step 22323. In Step 22322, FM Assoc, the program 
attempts to associate the file being processed with a Problem 
Fix Number. If the package is under Single Fix Mode, the 
default Problem Fix Number is associated to the file. If the 
package is in Engineering Change Mode and the repository 
already has existing Fix Numbers for that file, they are 
presented on a user screen. This is usually done with another 
interrogation of the Control Repository. The user is given the 
choice of selecting one of the existing numbers or entering 
a new one. If no Fix Numbers exist, the user is prompted to 
enter a new one. 

In Step 22323, the program checks to see if the Part 
Number Control Level is being crossed by comparing it to 
the Etestination Level provided by the user in Step 22301. If 
the answer is "yes", then the LFT PN, or Library File Type 
Part Number, flag is examined for each LFT being pro- 
65 cessed. If the flag is on, Step 22324 is invoked, otherwise the 
program proceeds to Step 22325. In Step 22324, PN Assoc, 
the program attempts to associate the file being processed 
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with a Part Number. If the repository already has an existing For any Fix Number or Part Number not associated with an 

Part Number for that file, it is presented on a user screen. EC, the program prompts the user to select an EC from a list 

This is usually done with another interrogation of the of existing EC Nimibcrs or choose a new one. ^ 

Control Repository. The user is given the choice of selecting Upon completing the loop, the Check Option flag in Step 

the existing PN or entering a new one. If no Part Number 5 22319 is examined again. If this flag is oflf, the program 

exists, the user is prompted to select a new one. proceeds to Step 22345 in FIG. 14/ Otherwise, if the user 

Since Steps 22321 through 22324 may be repeated for a requests the option, the Level Loop m Step 22333 is again 

large number of files, the Design Control System may be J^*^" ?^^P 22337. Lock Check is performed to ensure no 

implemented in such a way that the DMS server returns all ^^^^^ exist agamst the fi^e at any of the levels being 

associated Part Number and Fix Management data for aU 10 traversed.pese include Update, Move, Overlay and ft^- 

files being processed with one large query. The cUent then ^ff^l^^^'^l* ^.i^Sff^in^'/n^;^^^^ c^'tt 

. . , , ^ « . . r an owner or a surrogate of the owner. lo the latter case, the 

sifts throug^ the data to find the mformation necessary lo ^ ^^^^ o^ortunity to reset the lock, upon which 

mteract with the user. The algorithm states the mformation notification would be sent to the current owner, 

that must be obtamed from the Control Repository and the g^^p 22338, the User's Audiority is checked to ensure 

user, but permits a great deal of flexibiHty in the way it is 15 promote the file to that level. Finally, in Step 22339, 

acquired. a complete BOM Invalidation check is performed There are 

At this point the algorithm continues with Step 22325, two forms of this check. In the simplest case, the file is not 

Dest^Entry in FIG. 14d, In this step; the code determines if a BOM, so the control repository'is examined to see if any 

this is a simple Put or a Put/E>iomote combination by other BOMs will be invalidated by the movement of this file 

comparing the Destination Entry Level with the Destination 20 to the Destination Level. In the more complex case, the file 

Level. If they are the same, it's considered a simple Put. In is a BOM. Here the same check is made as in the simple 

this case the code proceeds to Step 22319. If the Target Level case, but additional checks must be made for every member 

is higher than the Entry Level, it's considered a Put with of the BOM to determine if their movement will invalidate 

Promote and continues to Step 22332. any other BOM. In either case, the results of the pending 

Returning to the Put/Prom decision in Step 22315, if the 25 invalidation are displayed for the user to examine, using our 

user is requesting a promote, the code branches to Step Aggregate Manager for this check, as BOMs may have 

22326 in FIG. 14c. Here the control rq)ository is queried to many members. 

find out whether the file being promoteid is the anchor file to It should be noted that the order of Steps 22337 through 

a Bill of Materials (BOM). Regardless of the outcome, the 22339 is not critical and is combined into single large 

Model Option flag in Step 22327 is examined. The answer 30 queries in our preferred embodiment. Files being promoted 

to both questions yield four possibilities. If both answers are from a Private Library into a Public Library employ the 

"yes" or both answers are "no" this is the normal case in QRSUPGET function, while promotions within the Public 

which the algorithm proceeds lo Step 22330. If the file is a Library utilize the QRSUPCHK routine, described in FIG. 

BOM, but the BOM Promote Option was not specified in 16. Upon completion of these checks for each level, the 

Step 22301, the Anchor Only Option flag in Step 22328 is 35 program moves on to Step 22340 to ensure the File Exists 

examined. If this flag is on. then the user is requesting to This not only means the file physically exists with the proper 

promote only the anchor file and not the entire BOM. If the nomenclature in the directory corresponding to the Source 

flag is off, a warning is presented to the user requesting that Level, Package, Version and Library File Type, but this also 

either the BOM Promote or Anchor Only Option must be means the control repository agrees that the file exists in that 

selected. Finally, if the file is not a BOM, but the user 40 location. If for example, the user believes the file is at Level 

specifies the BOM Promote Option, an error messagje is A, but the control repository is tracking it at Level B, this is 

displayed and the program temiinates. a data integrity violation and the promote ceases. 

Cbntinuing with Step 22330, the program checks to see if At ttus point, the algorithm proceeds to Step 22341 in 
a BOM exists at any of the levels being promoted through FIG. 14e, where the question "is it a simple Promote" is 
with the same name as the file. If so, a warning is issued, in 45 asked. If so. Step 22342, Crichk is performed. For a pro- 
Step 22329, to the user indicating a BOM will be and motion beginning at a library level (not one that is chained 
subsequently deleted if the promote continues. The user is to a Put), the control repository is queried for any Post- 
given the option to continue or abort the operation. If no Processes or DILPs defined at the Source Level. If there are 
BOM Overlay is imminent, or the user accepts the overlay, any processes, then the process results for the file being 
the algorithm proceeds to Step 22332 of FIG. 14cL so promoted are examined to ensure they meet the proper 

In Step 22332, Chk Lvl Order, the promotion path is promotion criteria. If any fail criteria, a warning is issued 

examined to ensure a legal path exists fi-om the Source Level informing the user that the promotion will fail, 

to the Destination Level. In the case of a Put, where the Next, Step 22326 is executed again to check if the file ;s 

Destination Level is not equal to the Entry Level in Step a BOM. If so, a Member Loop is set up in Step 22343 where 

22325, the Entry Level is also checked to ensure it's part of 55 each member has their process results checked against any 

the path. If not, an error is displayed and the program Past-ProoesseS or DILPs which exist for those LFTs at the 

terminates. Step 22333 is a Level Loop which must be set up Source Level. This checking is the same as Step 22342. 

so Steps 22334 and 22335 can be performed for each level If the answer to the Promote question in Step 22341 or the 

in the promotion path. BOM test in Step 22326 is ''no" the code proceeds to Step 

Step 22334. EC LVL^ is where the program checks to see 60 22345. Likewise if the Member Loop in Step 22343 was 

if the EC Level is being crossed during the transport This is exercised, the code proceeds upon exit to Step 22345 in FIG. 

done by determining if the Destination Level entered in step 14(; In Step 22345, Fproc Option flag is examined to see if 

22301 is at or above the EC Control Level. If the test the user is bypassing Foreground Processing. If the flag is 

resolves to a "yes" answer, the program must perform step off, the code retums to the top of the File Loop in Step 

22335, EC Assoc. Here it queries the Control Repository for 65 22314. If the flag is on. the Level Loop in Step 22333 is 

EC information regarding any Problem Fix Numbeis and initiated again. For each level that the file will pass thru. Step 

Part Numbers selected or entered in steps 22322 and 22324. 22346, Fproc will be called. 
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In the Fproc step the code queries the control repository 
for all foreground processes defined for that Library File 
Type at that level, version and package. Each process is then 
executed imnaediately in sequence so the user can enter the 
appropriate responses. These foreground processes are 
established by the Data Manager. Upon cx3mpletion of the 
Level Loop, the code returns to the File Loop in Step 22314 
of FIG. 14a. Once Steps 22314 thru 22346 are executed for 
all files in the promote request, the algorithm proceeds to 
Step 22347, Override Option. 

In Step 22347, the Override Option flag is examined. If 
it's off, the program proceeds to Step 22349. If it's on, then 
Step 22348, Override is executed. In this step the user is 
allo wed to override any of the proces s jaa rameters fia r the 
hbrary procc^es tha t will be exe gited during the promoti on . 
The' algorithm queries the controlrc pository for all Pre and 
Post-Processes defined for this Librarv File Typ e at this 
level; version and package. All of the process parameters are 
displayed on the screen, and the user can select and modify 
as many as desired. Once fini^ed, the user ''OK**s the 
modifications, and they are written into the control infor- 
mation which is used in the next step. The DMS will use 
these modified parameters to drive the library process, only 
if they exist. Otherwise it defaults to using those define by 
the Data Manager. 

In step 22349, Xmit, the program gathers and transmits all 
of the necessary data to the Design Control System. In our 
preferred embodiment, the destination would be an Auto- 
mated Library Machine which would access most of the 
information via a "copy** operation. The following types of 30 
information need to be transmitted: 

The type of request: Put, Promote, or Mixed 

The list of files being promoted. The following informa- 
tion must exist for each file in the list: 
The Filename 
The Library File Type 
The Package 
The Version 

The Source Level, Entry level. Destination Level 
Fix Numbers (if any) 
Part Numbers (if any) 
EC number (if any) 
Any user selected options that pertain to the background 
operation. 

The user's electronic id or e-mail address. 
Information gathered during any foreground processing 
that occurred. 

Information relating to any process parameters altered 
during the Override operation. 

In addition, for Put operations the fiiles themselves must 
be transferred from the user's private library. This includes 
all existing members of Automatic File Groups. Our pre- 
ferred embodiment performs this by either having the Auto- 
mated Library Machine copy the files or by sending them. 
The determination is made based on a user option called Via 
Copy which exists on the main input menu in FIG. 13. One 
other option on the main menu is the Emergency option 
which informs the DMS to treat this as the highest priority 
in the processing queue. This feature enables critical work to 60 
be processed ahead of older jobs. 

Returning to RG. 12, the algorithm proceeds with the 
Background processing in Step 22103. In our preferred 
embodiment, the promote request from Step 22102, Fore- 
ground is transmitted to an Automated Library Machine 65 
(ALM) for processing. The first step is for the ALM to Read 
Control Information which is done in Step 22411 of FIG. 



15fl. Here, the names of files in the promote request are 
stored into a data stmctiu'e along with all pertinent control 
information like Problem Fix numbers, Part Numbers, EC 
Numbers, Entry Level & Destination Level for each file, and 
the user options. The options are further parsed to set flags. 
In our preferred embodiment, these requests are homog- 
enous which means all files in the request move from the 
same source to the same destination. Since the Foreground 
step determined the type of request, it's contained in the 
control information and used to set the flag which is exam- 
ined in Step 22413. 

However, our embodiment also supports heterogeneous 
file movement. An example of this is two files where one 
moves from level A to B while the other moves from level 
C to D. Although this request can't be generated by the 
Foreground process in Step 22102, it can be created by 3rd 
party tools interfacing with the DMS. To accommodate this, 
the control file indicates the type of request as Mixed In this - 
case. Step 22413 must employ the same algorithm used in 
£0 the Input Files step of FIG. 14ii to determine if the request 
is a Put or Promote on a file-by-file basis. Since the control 
information contains the Source, Destination and Entry 
Level for each file, this is quite easily done. At this point, the 
File Loop in Step 22412 is entered in order to execute Steps 
25 22414 thru 22418 on each file in the request. Step 22413 
checks to see whether the request is a Put, Promote, or 
Mixed where: 

Put means all files in the request are being promoted from 
a private library into the same level of a shared public 
library. The files may have to be promoted one or more 
times to reach the destination, but all files will travel the 
same path. 

Promote means all files in the request are being promoted 
fi-om one level of a shared public library to another. The 
files may have to be promoted one or more times to 
reach the destination, but all files will travel the same 
path. 

Mixed means the request contains a mixture of files where 
2 or more files may travel different paths. In this case 
the background algorithm must determine the promo- 
tion path for each individual file. 
Note: Our preferred embodiment does not allow this 
type of request to be generated from the Foreground 
user interface, but 3rd party tools may create one. 
In the case of a Promote (ie. the file is being moved firom 
one level of the DMS to a higher level). Step 22414 is 
employed to set an Overlay Lock on the file. The DMS uses 
this Overlay Lock to prevent a different ALM from moving 
the same file while this request is in progress. Next, Step 
22415, Promote Check is called upon to do the following 
checks: 

Ensure that the Source Level is valid and not a frozen 

Release Level. 
Ensure that a valid path exists from Source Level to the 

Destination Level. 
Determine the next higher level above the Source Level. 
(This may not be the Destination Level if this is a 
multi -level promote). 
Obtain the physical location of the Source and Destination 
Levels. 

Ensure the user is authorized to do this promote. For 
regular promotes, the user must have normal promote 
authority whereas for BOM promotes. Model Promote 
authority is required. 
Ensure the file really exists in the DMS at the expected 
Source Level. 
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Check for any Processing or Move locks. Also look for Step 22421, il may have required work to be dispatched to 

any Overlay Locks at the next level. other ALMs. In this situation, the DMS maintains data 

Check all Post-Process and DILP criteria at the Source integrity by setting a Processing lock in the Process Queue. 

Level to ensure the file meets all of the criteria. In the If the current ALM detects an outstanding lock in Step 

case of a Bill of Materials (BOM) promote, each 5 22422, on the file being processed, it will recycle the 

member of the BOM is also checked to ensure all promote request until the lock is cleared. This ensures that 

criteria is met. tbc order of execution for library processes is always main- 

If the file is crossing the EC Cbntiol Level, and the file is ^^^^ regardless of the distribution of workload, 

under Problem Fix Management, check to ensure a Continuing with Step 22423, a special option flag denoted 

proper EC number is provided, ^° ^ogp is checked. If it's set, the promotion terminates 

IfaBOMPromoteisrequested,acheckismadetoensure successfully even though no files were actually transferred. 

a BOM is associated with the file being processed. * ^he DMS uses to mitiate library 

If a processing lock is detected, the promote request is processing against a transient file which doesn I need to be 

recycled back into the DMS queue to await completion of Permanently retained For example a transacUon file may be 

the library process 15 promoted into the DMS for the sole purpose of mitiatmg a 

Note: If a ptocessiog lock exists, special hang detect code jjb'aO' process to update a master file residing in the library, 

is used to determine if the file has been locked for an 9°** ^''}^ "P^'*"^'. theJransacUon file is do 
unuiialiy long-^riod of tinie.Tf i., thili^f is Stifia -aniJ "^°8Pr necessary so it can be dis«irded. ln;this casej-the- 

advised to check on the process job. ^ "P'"?" ^^"^^ f^V^^ ^f"? 

ReturaiDg to Step 22413, if the request is a Put, then Step fcmng and deletmg the file If the Nogo option doesn texist, 

22416 in no. 15 is employed to see if Update Locks Exist <»ntrol proceeds vath anotiier File Loop 

in the user's name, at the Destination Entry Level, for the file ^ *8*»"' ^tep ^12 is invoked to loop through all 

being processed. If not, one is acquired in Step 22417, Updt «>. ^ »«P f«L »° 

Lock TOs lock may be permanent or temporary depending t^'^J, Promote In the case of a Put, 

on the setting of a user controlled option which is discussed " Step 22424, Sup Put is exercised In om preferred 

later. The reason for setting it at this time is to prevent em»»diinent. this is i^rformed v« Ih^^^ 

someone from taking owneisbip of the file while the Put is responsible for updating all the neoesswy tables to 

in DroETcss mdicate that the file now resides in the new Entry Level 

In Step 22418, Put Ched<s. a series of checks are per- """'I""- addition, •he Control Repository examines the 

formed against the file. Many of these are duplicates of those '° ^'"''e';"""* '"'l^*^ ^"^^i ^i^^ fT 

nmintbeForegroundinStep22102.iftheuserspecifiedthe ^"^^ J^'^'^T' Le^<l(PFVL). It also 

Check option during Step 22101. In our preferred checks to see rf the EC or Part Nmnber Control Levels are 

embodiment, these checks are all done with a single query ^'""f. crossed. Dependmg on the results of these flags and 

to the Control Repository. The following are performed: '^^^ V ^^'^ ^ corresponding Problem Fix numbers, 

. , ^ wv_ . m* 35 Part Number and/or EC Number to be available. This 

A check .5 m«ie to ensure no Processmg. Move or ^^^^^ step 22102, Foreground 

Overlay locks exist on the file^ Process H,e DMS updates all tables Lociated with Prob- 

EMures the user is authorized to Put this file to the Entry pj^ Management and Part Number control at this time. 

^® If the file is overlaying an older version of the same file, the 

The physical location of the Entry Level and Source Level 4^ Problem Fix numbers from the old file are appended to those 

are acquired. jjg^ gj^ p^y previous iteration of the file, at a higher 

The File Reference number is generated. level, with the same Problem Fix Numbers as the file being 

The Lock Reference number is acquired. promoted will result in the higher level Problem Fix Num- 

TTie Entry Level is checked to ensure it's a valid entry bers being Superseded Also, the locations of the File Group 

point into the DMS. It may be a Sideways Release 45 subordinate files are updated. If this query completes 

Level, but not a regular Release Level. successfully, the file is oflBcially promoted into the DMS, 

If any of the checks fail, the promotion terminates with an even though the file hasn't physically been transferred yet. 

appropriate error message. In order to maintain absohite data integrity, the DMS always 

At this point the File Loop in Step 22412 is repeated until has the correct information. If a file physically resides in a 

all files are exhausted. Upon exit from the loop, control so state other than that reported by the DMS using a query, the 

proceeds to Step 22419, List Files. Here, the file information file is in error and needs to be rectified, 

is re-written with the source and destination physical loca- If Step 22413 determines the request is a Promote, Step 

tions in preparation for the upcoming file transfer. The file 22425, Sup Prom is invoked. In our preferred embodiment, 

name of this control file indicates whether the file transfer this is a accomplished by the QRSUPPRM routine, which is 

pertains to a Put or Promote. ss responsible for updating all the necessary tables to indicate 

Upon completion of List FUes, the Pre-Processing Done that the file and all File Group subordinate files now reside 

flag is examined in Step 22420 of FIG. 15c. The flag is set at the level above the Source Level. For BOM promotes, the 

to *'Done" if no Pre-Processing is required, or whenever the tables for all member files previously at the Source Level arc 

Process Manager completes all required PreProoesses. If the updated as well. Members currently at the Destination Level 

answer is "no", then the Process Manager, in Step 22421, is 60 or higher, or members in other libraries, will not be affected, 

employed to run any pre-processes that exist. Tlie Process In addition, the Control Repository examines the Part Num- 

Manager processes all files in the list with a single invoca- ber flag for the current Package, Version, Level and LFT. If 

tion using the control file generated in Step 22419. If any of it exists, and the Part Number Control Level is being 

the pre-processing fails, the promotion with an appropriate crossed, it expects the conesponding Part Number to be 

error message. At the completion of the Pre-Prooessing, the 65 available. Likewise, the DMS checks to see if the EC Level 

Preprocessing flag is set, and the Process Queue in Step is being crossed, and if so, the appropriate EC Number must 

22422 is interrogated. Although the processing completed in be present This information was gathered during Step 



04/19/2004, EAST Version: 1.4.1 



5,950,201 

43 44 

22102, Foreground Process The DMS updates all tables locations are identical, or it could result in the file(s) being 

associated with Problem Fix Managenaent by appending any physically moved from one server to another. The exception 

new Problem Fix Numbers to any existing numbers pertain- lo this is if the Retain Source option is specified on the 

ing to the previous iteration of the file. Any previous promotion screen in Step 22101. This would result in 

iteration at a higher level with the same Problem Fix 5 copying the file(s) from the source to the destination. 

Numbers as the file being promoted, will result in the higher For a BOM Promote, a list of all BOM members is 

level Problem Fix Numbers being Superseded Subsequently, returned by the Control Repository in Step 22425. All 

the DMS attaches all Emblem Fix Numbers for this file to members on this list are moved in the same manner as the 

the EC Number. Also, the Part Number tables are updated. Anchor file indicated in the main File List, 

as necessary. lO Similarly, if the current file is the Master of a File Group, 

At this point control proceeds to FIG. ISd where varioiis a Usl of all subordinates are returned from the Control 

flags must be checked, and possi'ble additional actions taken. Repository during Step 22425. This list is used to move all 

In Step 22426, BOM Ovly, the Sup Put or Sup Prom return the subordinates to their target destination, 

code is checked for an indicator that an existing BOM was For environments incorporating Automated Library 

overlaid by this promotion. If so, then Step 22427, Send Msg is Madiines, the ALM must have a means to access and update 

is invoked to send a message to the owner of the BOM any data within its own library. Whenever possible, all 

informing them of the BOM eradication. Next, Step 22428, ALMs in a given library are provided with read and write 

"Erase Toll -Fig is invoked to check if a file group exists for - authority toall physical data lepositorks. For example, in a ■ 

the file being promoted. If so, and the Erase-To-Level flag is simple DMS all data within a library would reside in a single 

set, then Step 22429, Erase Fig is invoked. Here, the 20 directory, and the ALM would have read and write authority 

program determines whether the subordinate file will be to that directory. However, since our embodiment permits 

replaced by an incoming file. If not, the existing subordinate different PFVLs to reside in separate repositories^ this can't 

file is erased and a message is sent to the owner informing always be achieved. For instance, one PFVL may reside in 

them of the file removal. a Unix or AIX directory, while another PFVL resides on a 

In Step 22430, the BOM Invalidate flag is checked. This 25 VM Minidisk. An ALM running in the Unix/AIX environ- 

indicates that the promotion of this file caused one or more ment may not have direct write access to the VM Minidisk. 

BOMs somewhere in the DMS to be invalidated. This would The following algorithm is used to handle all types of file 

happen if this file is a member of some other BOM. A movements in the DMS, depending on the ALM configu- 

sophisticated algorithm exists in the DMS to quickly check ration and platform environment. 

all BOMs in the system for the presence of this file. If an 30 In order to maximize efficiency, the ALM wiU always try 

invalidation occurs, Step 22431 is invoked to Notify BOM to rename or move a file if the envirorunent supports such an 

Owners exactly which BOM was invalidated and which file operation and the source and target PFVL reside in an 

caused the invalidation. It should be noted that Steps 22426 amenable environment such as two Unix/AIX directories 

and 22428 and 22430 can be checked in any order. (same or different) or the same VM Minidisk. In this case. 

The algorithm continues with Step 22432, Move Files. 35 the ALM attaches to the target repository in a writable 

The method for moving data is very dependent upon several manner, and performs the move operation. Otherwise, the 

factors. These include, the system environment, the existence operation is performed by a combination of file copy fol- 

and/or arrangement of Automated Library Machines, and the lowed by file deletion. In this case, the algorithm first 

user options selected during initiation of the Put or Promote. determines if both the source and target repositories are 

If no ALMs exist in the DMS, it's assumed that the user's 40 writable by the ALM. Such is the case for a Conventional 

client envirorunent has the proper read and write access to ALM system or an Actor/Object system running in a Unix/ 

the data repositories. The code uses the appropriate combi- AIX environment. Here, the ALM directly performs the 

nation of copy, delete and/or rename commands to accom- copy from the source to the target PFVL. Once the file is 

plish the desired Move operation. However, if ALMs are safely copied, the ALM deletes the source file. In an Actor/ 

employed, a Move algorithm is used to determine how this 45 Object configuration in a VM environmeat, the Actor must 

step is implemented. This algorithm is discussed in more send a message to the Object and pass a list of files to be 

detail below. For the moment it's assumed that a method is copied and deleted. The Object runs a continuous message 

in place to copy, delete, and/or rename files throughout the handler which allows multiple Actors to interrupt and ini- 

entire DMS. tiate the copy and deletes. For situations such as a Conven- 

In our preferred embodiment Step 22432 is usually done 50 tional ALM arrangement running on a VM system, where 
with a file copy for a Put operation, but the system does the source and target PFVLs are on different account 
support an environment where files can be sent, or otherwise Minidisks, the ALM handling the promotion always has 
transmitted. To accommodate this, a special option called write access to the target PFVL. Therefore, it can directly 
"MaCopy" exists on the main promotion menu. It defaults perform the copy operation. The delete is handled by gen- 
to an ""on" position, but can be turned off to signify that the 55 erating a file deletion request similar to that generated by 
data files are being sent to the ALM 's reader along with the the. File Deletion routine. This job request is transmitted to 
control information. If the files are sent, they must be ''read" the ALM with write authority for the source repository, 
into a temporary holding area while the promotion process For promotions involving the movement of data across 
takes place. Otherwise, they can reside in the user's private different platforms, our embodiment incorporates the con- 
space until the actual transfer takes place. At this point the 60 cept of a Cross-Platform Transfer. The method differs 
file is physically copied from the source location to the Entry depending on the source and target platforms. Our embodi- 
Level. In addition, any subordinate files that belong to this ment wiU always try to use the ALM currently executing the 
file's Automatic File Group are also transferred to their Promotion algorithm to link to the target platform directly, 
destination. In these cases, the underlying Actor/Object code sets up the 

For a promote, the preferred method is to move the file(s) 65 appropriate file transfer protocol and copies the file from the 

from the source location to the destination location. This source to the destinatiorL It then deletes the file fi-om the 

may result in a simple rename of the file(s) if both physical source repository. The most complex case is when the target 
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environment can't be linked directly by the ALM. Such is 
the case when the ALM is running in a Unix/AIX 
environment, but the target PFVL is on a VM Minidisk. 
Achieving this file transfer involves using dedicated ALMs 
running on the source and target platform, which serve as 
agents to forward the work requests. The following steps arc 
performed: 

1. The ALM prepares a special Cross-Platform Transfer 
request file which contains the source and target level, 
the userid of the requester, the type of promote, and a 
list of all files that need to move. This request file and 
the origiaal promote request are copied into a special 
punch directory whose name is also contained in the 
request file. 

2. The ALM currently processing the promote, establishes 
a socket connection with the VM agent to request a file 
transfer to VM. 

3. The VM agent copies all the data firom the punch 
directory, and the Cross-Platform Transfer request file 
to its working space. 

4. The request is sent to the appropriate VM Actor, where 
it's handled by Steps 29162 and 29163 of the ALM 
algorithm. This algorithm is described in detail in FIG. 
55c. Step 29163 takes care of transferring all the data 
as well as deleting the copies from the source reposi- 
tory. 

5. At this point, the code exits the Promotion algorithm, 
and the remaining steps in RG. ISd and 15^ are 
performed by the code executed in Step 29163 of the 
ALM algorithm. 

Note: Our embodiment only supports Cross Platform 
promotions using Actor/Object arrangements. 

An altemate embodiment permits all the files in the DMS 
to reside in the same physical location. Symbolic links 
would serve as place holders and reside in the locations 
defined by the Data Manager for eadi PFVL. During a Put, 
the link would be created while the file is being copied to the 
master location. During a Promote, the file would be 
renamed and the corresponding link would be updated. 
Depending on the environment, this may provide perfor- 
mance or data maintenance advantages over the preferred 
embodiment. 

The last step within the File Loop pertains to the Update 
and Overlay Locks established in Steps 22414 and 22417. In 
Step 22433, Rst Lock, the Reset Lock Option is examined. 
If it's on, this signifies the user's desire to leave the file in 
an "unowned" state at the completion of the Put or Promote, 
and the program resets any Update Lock that exists for this 
file at the new level. For promotes, an additional step is 
taken to reset the temporary Overlay Lock set in Step 22414 
regardless of the Reset Lock Option. 

Control is returned to Step 22412 in FIG. 15c until all files 
in the request are exhausted. Upon exit from the loop, 
control is passed to FIG. 15^. Here Step 22427 is again 
invoked to send a message to the user indicating a successful 
Put or Promote. The message includes the names of all files 
processed including Automated File Groups and members of 
a BOM. 

Next, the DMS again invokes Step 22421, Process Man- 
ager to run any Post-Processes that exist for any of the files. 
Just like with Pre-Prooesses, the Process Manager handles 
the entire list of files with a singk invocation. ^ 

Hiat last steps in the operation attempt to determine 
whether additional promote requests are necessary. In Step 
22434, Prom Req'd, the Destination Level is compared 
against the current level for eadi file in the list. For Puts, the 
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current level is the Entry Level. For promotes, it's the 
Source Level. If any files are found with a Destination Level 
higher than the current level, this indicates that further 
promotion is necessary, and Step 22435, Promote, is invoked 

5 to handle this. In this step, a promote request is actually 
created listing all files which require further movement. The 
control file also lists their newly acquired level as their 
source level and lists their Destination Level as the target 
level. The entire background algorithm is repeated with Step 

IQ 22411, but using the newly created promotion request as the 
main input control file. Once the current level and Destina- 
tion Level are the same, the promotion is complete. 

Methods of Storing, Retrieving, and Managing Data in a 
Shared Library System 

IS The present embodiment incorporates various algorithms 
and processes to permit data to be stored into, deleted, and 
retrieved from the Data Management System while main- 
taining absolute data integrity. The Data Management Sys- 
tem (DMS) is comprised of one or more shared public 

20 libraries servicing one or more users in a client server 
environment. The users may also have private libraries 
where work is performed imtil such time that it is ready to 
be deposited into a public Hbrary for shared access. Our 
embodiment has the capability to provide continuous access 

25 of the shared libraries to large numbers of users. 

These algorithms and processes are especially suited to 
interacting with the File Promotion Process and Automated 
library Machines (described in the other sections of the 
Preferred Embodiment), although they will work without 

30 Automated Library Machines and with other File Promotion 
Algorithms. 

In order to safely deposit data into the Data Management 
System, our preferred embodiment uses an Installation 
Algorithm described herein. The algorithm is depicted io a 
3S library environment using Automated Library Machines 
configured in any arrangement, although one drilled in the 
art would aj^reciate that the algorithm can function in the 
absence of ALMs simply by executing in the client's fore- 
ground environment. 
4Q The most frequent initiator of install requests is the 
Process Manager. The Process Manager executes Automated 
Library Processes which create output data that must be 
deposited into the DMS. Our embodiment maintains close 
ties between the output data and the sotirce data used to 
45 create it. If this output data can't be successfully installed 
into the DMS, the source data may be prevented from 
moving through the DMS or undergoing further processing 
until the problem is corrected. Because of the multitude of 
different types of Automated Library Processing, our pre- 
50 ferred embodiment contemplates several types of install 
requests combined with a plurality of user options. 
The following types of installs are supported: 
Regular Install Deposits the output into the DMS under 
full data control. The output file may or may not be 
55 assigned a File Reference number and completely 
tracked by the Control Repository. Once installed, the 
file can be processed like any other file in the DMS. The 
install can be immediate, whereby the install is initiated 
and further processing suspends until it completes, or 
60 the install can be delayed which means further process- 
ing may continue while the Library Manager processes 
the install request. 
High Performance (HP) Install Similar to a Regular 
Install, except it deals with groups of component files. 
65 This occurs during an Aggregate Install which always 
begins with an Anchor file undergoing a Regular 
Install, followed by all the related components under- 
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going a High Performaace Install. The informatioD 
necessary to install the group of files is conveyed 
through a special file traosmilted with the Install 
Request 

Create DILP Install Used only on the output file of a 
Create DILP. This install is identical to a Regular Install 
with some additional steps that assign the process result 
to the output file once it's safely in the DMS. The 
necessary information is passed to the Install algorithm 
through a special file transmitted with the Install 
Request. 

Regular Store Deposits the output into the Data 
Repository, but the file is not tradced by the Cbntiol 
Repository. These files exist for some other reason than 
data management, and don't require any DMS opera- 
tions (promote, library processing, problem tracking, 
etc.). This type of di^iosition can be immediate or 
(telayecl! " 

The following options arc supported for the above types 
of installs: 

Result: Allows Pseudo Process Results to be set against 
files being installed. 

Note: All information is exchanged via a Results File 
Part Number: Allows Part Numbers to be assigned to files 
being installed. 

Note: All information is exchanged via a Part Number 
File 

Resolve: Allows Library Process Results to be primed for 
files being installed as long as the process structure for 
the installed files is identical to that of the source files. 
For example, if a file is copied firom a source PFVL to 
a target PFVL, since the installed file is identical to the 
source file, any Library Process results for the source 
file can be automatically propagated to the target file. 
Note: All information is exchanged via a Resolve File 
Now, the program begins by receiving an Install Request 
The Install Request contains the target Version and Level, 
the e-mail address of the user initiating the request, the File 
Name, Type and Package of the subject of the install, the 
Level Reference Number, one or more File Reference Num- 
bers representing the data which was used to create the 
subject data, a multiplicity of user options, and a flag 
indicating whether a new File Reference number should be 
acquired for the subject data or whether an existing refer- 
ence number should be retained. This information is gener- 
ated by the algorithm responsible for creating new data 
which needs to be installed in the DMS. A typical example 
would be our Background Automated Library Processing. 

In a Conventional System, this request may be transmitted 
from a Remote Execution Machine to a Primary ALM 
whose responsible for installing the data. In this case, the 
Install Request contains additional information regarding 
the Process Manager's Process Queue. This includes the 
Library Processing Phase (Pre, Post or DILP), the File 
Reference of the file used to set the Processing Lock and the 
Process Queue Reference Number. A Checksum or Cyclic 
Redundancy Code is also inchided to help detect transmis- 
sion errors in the data. In an Actor/Object arrangement, the 
Actor can execute this algorithm directly, so there's no need 
to transmit the request. In this situation, no Process Queue 
entry is required and no CRC code is needed. However, the 
Install Request file is still created. 

The algorithm begins with Step 24910, which Reads the 
Request File into a data structure. In addition any user 
options arc examined and for those requiring separate sup- 
port files^ the file names are assembled. The program also 
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determines whether the ALM currently executing the algo- 
rithm is an Actor, and if it's not an Actor it checks to see if 
the request was sent from a different ALM. If so, the 
information in the Install Request is written into an Install 
5 Recovery file which is used by the ALM Algorithm to 
recover the instaU in the event of a system crash. Also, in a 
the case where the Install Request is transmitted, the subject 
data is also transmitted, so it is transferred into the ALM's 
working space. 

10 Next, Step 24911 is invoked to perform a Data Access of 
the physical repository where the subject data will be 
deposited. This may be as simple as ensuring the ALM has 
the proper write authority (such as a Unix/AlX environment) 
or it may require linking media sudi as DASD in a VM 

15 environment. 

Step 24912 tests for Return Codc=0 from the previous 
step. A non-zero return code indicates that one or more 
■physical repositories could not be located or accessed in the 
proper manner. This results in Step 24913 being called to 

20 possibly clear the Process Queue. Step 24913 tests to see if 
the Install Request was transmitted by a Remote Execution 
Machine. If so, the Process Queue Reference Nimnber is 
used to delete that entry from the queue. Furthermore, if an 
entry exists and the Process Phase is a Pie-Process, then a 

25 special entry is added to the Process Queue in order to 
prevent any subsequent Library Processes or movements 
OGCuiring against the source file used to generate the subject 
file being installed. This maintains data integrity in the DMS 
by ensuring that output data always matches input data, and 

30 input data may not be elevated to the next level unless all 
required Library Processes run successfully and the output is 
successfidly deposited into the repository. Upon completion 
of Step 24913, the requestor is notified of the failed instal- 
lation attempt and the program exits. 

35 Returning to Step 24912, if the Return Code equals zero, 
then the physical repositories are ready to accept the data 
and control proceeds to Step 24914. In Step 24914, the Actor 
flag, set in Step 24910 is examined. If the flag indicates that 
the current ALM is not an Actor, then the Install Request was 

40 transmitted with a Cyclic Redundancy code which pertains 
to the data being instaUed. The program generates a new 
CRC Code using the subject data in the working area and 
compares this with the code embedded in the request file. If 
they don't match, a transmission error occurred which is a 

45 data integrity violation. This results in a message being 
returned to the requestor, and the program aborting. 

Assuming the transmission occurred successfully in a 
Conventional System, or if the ciurent ALM is an Actor, 
then control continues with Step 24916 which sets the Fix 

so Management Flag This flag is passed to the imderiying 
QRSUPGEN routine to tell it whether to propagate the 
Problem Fix Management data from the source files to the 
subject file. This flag is set to "true" if the Package is in 
Single Fix Tracking or Engineering Change Mode and the 

55 Library File Type has its Fix Management flag active. 

At this point, control is passed to Step 24918. In the 
preferred embodiment, Step 24918 is exercised before Step 
24922, but these are independent tests which can be per- 
formed in either order. In Step 24918, the Create DILP 

60 option is examined. If the current request is for output 
generated by a Create DILP, then Step 24919 is executed to 
Read the Create DILP Info. This information is stored in a 
separate file which accompanies the Install Request and the 
subject data. The file contains the true name of the output 

65 file, which may differ from the name contained in the Install 
Request. Create DILPs are part of our library process. This 
file also contains the Log and Process Reference Numbers of 
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the library Process which created the file, and the Library 
Process Return Code. Step 24920 is then invoked to Create 
Recovery Information. This consists of generating a Create 
DILP Recovery File which includes all the information in 
the Create DILP file along with the corresponding Control 5 
Repository command required to store the information in the 
DMS. In the event of a system crash, the ALM Algorithm 
will use this file to exercise all the steps necessary to recover 
and complete the installation. 

Finally, Step 24921 performs a File Copy into the reposi- 
tory. The file is copied here temporarily so it's sure to exist 
in the event of a crash. However, if the subject file is 
overlaying an existing file, the existing file is backed up first. 
This enables the ALM A^orithm to completely and accu- 
rately reproduce the state of the DMS if the subject file is 
unable to be properly installed. A flag is written into the 
recovery file indicating whether an overlaid file has been 
backed i^. 

If the current rcquest'is not for a Create DILP, then Step 

24922 is employed to test for a High Performance install. 
This option can be requested to install a group of files. Our 20 
embodiment requires that at least one member of the group 

to act as an Anchor file. This means it must endure all the 
normal checking of a regular install. The remaining files 
benefit from the High Performance install which eliminates 
certain checks that are redundant to those done on the 25 
Anchor fik. The list of files to be installed is maintained in 
a separate file transmitted with the Install Request. Step 

24923 Reads the File List into a data structure that will 
eventually be passed to the Control Repository. 

Step 24924 is then invoked to Access All the Repositories 30 
necessary to accommodate the entire list of files. Since our 
embodiment permits the list to include files of differing 
PE^VLs, and files may be physically segregated down to the 
PFVL granularity, a plurality of repositories may have to be 
acquired. The method of access is identical to that performed 35 
for the subject file in Step 24911. 

Whether the tests performed in Steps 24918 and 24922 
arc true or not, control eventually reaches Step 24928 which 
Updates the Control Repository. This step consists of updat- 
ing all the necessary tables with the information required to 40 
track the subject file(s). In the case of a Create DILP or 
regular install, the QRSUPGEN routine, is called. In addi- 
tion to the File Name and PFVL information, the algorithm 
also passes the New File Reference flag, the Problem Fix 
Management flag, and any of the Source File Reference 45 
numbers pertaining to the source data used to create this 
data. In the case of a High Performacx:e install, the same 
information is passed with the exception of the Problem Fix 
Management flag. Instead a list of the entire file group is 
passed. If an error occurs, sudi as the existence of a lock 50 
which prevents the install, and this is a Create DILP which 
necessitated the back up of an old subject file in Step 24921, 
then the backed up file is restored. All severe errors during 
this step result in a message being sent to the user, followed 
by the immediate termination of the installation. 55 

If no severe errors occurred during Step 24928, then 
control proceeds to Step 24930 in FIG. 33c. Here ibc return 
code of QRSUPGEN is examined for a Bill of Materials 
(BOM) Invalidation Message. Two types of warnings exist. 
One case is when the subject file overlays an existing file 60 
which happens to be the Anchor of a BOM. In this case, the 
BOM is deleted and the owner of the BOM is notified. The 
other case is when the subject file overlays a file which is the 
member of a BOM. Id this case, the BOM becomes invalid 
and the owner of the BOM is again notified. 65 

Next the program again invokes Step 24918 to test the 
Create DILP option. If this is a Qeate DILP install, then Step 
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24932 is employed to store the Process Result into the 
Control Repository. This result, along with the Process and 
Log Reference Numbers are contained in the Create DILP 
file. Since a Cteate DILP requires the Library Process result 
to be recorded against a file that doesn't exist when the 
process completes, the Process Manager must forfeit the 
setting of the LP result to the Install algorithm. Once the 
result is set in the Control Repository, Step 24933 checks to 
see if an overlaid backup file exists from Step 24921, and if 
so, it Erases the Backup file. It also erases the Create DILP 
recovery file, ance all the steps that can be recovered have 
succeeded. 

Control eventually reaches Step 24934 which Deposits 
the File into the data repository. The program checks to see 
whether the cut-rent ALM is an Actor. If so, and the 
environment allows the Actor to have direct write authority 
to the repository (such as Unix/AIX), the ALM copies the 
subject file fi^om the Actor's- working -space to *the~tatget — 
repository. If it's an environment such as VM, then the Actor 
establi^es a conununication link with the corre^nding 
Object ALM, and requests the file copy. If the current ALM 
is not an Actor, then it must have write authority to the 
repository, so it simply copies the file from the working 
space to the physical location. If the current install request 
is for a High Performance install, the same steps are run 
against each file in the file list except for the Anchor. The 
Anchor is bypassed since the definition of a High Perfor- 
mance install requires the Anchor to be instaUed separately 
using a regular install request 

Next, Step 24935 is performed to test for the Result 
Option. If this option is passed, then there are Pseudo 
Process results which need to be recorded against the subject 
file. Step 24936 is employed to Read the Results File which 
contains the Pseudo-Process Name, the result, an optional 
message, and the name and PFVL information of the file fiDr 
which the result should be recorded against. The code looks 
through the file for a matching file name and PFVL, and if 
one is found, it calls upon Step 24937 to Set the Pseudo. This 
is done via a function in the Process Manager to set the 
Pseudo-Process result into the Control Repository. Disclo- 
sxu-e # PO996-0009 contains more information on Pseudo- 
Processes and the implication Program Interface that allows 
other routines to set them. 

Eventually control passes to Step 24938 which tests for 
the Resolve Option. This option allows Library Process 
results firom a different PFVL to be recorded against iden- 
tical processes for the subject FFVL. If this option is passed. 
Step 24939 Reads the Resolve File which contains the 
Process Name, Process Reference Number, PFVL informa- 
tion where the source process resides, the Process Result to 
be recorded, the File Name and PFVL of the subject file and 
an optional Process Message. 

Step 24940 is then employed to Find the Matching 
Process. This is done by querying the Control Repository for 
all processes defined for the source PFVL. The code loops 
through the process definitions until it finds one whose 
Process Name and Reference Number match the information 
in the Resolve File. If no match is foimd, the information in 
the Resolve File is inaccurate, and the program terminates 
with a message sent to the user. If a matching process is 
found, the exact location in the process structure is saved. 
Next, the control repository is queried for the process 
structure defined for the subject PFVL. The same location in 
the process structure is examined to ensure the Process 
Name is identical to that listed in the Resolve File. If not, 
then the structures arc different, and the rule regarding use 
of this option is violated, thus causing the process to abort. 
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If ihe Process Names match, the Process Reference of the of the file. Fields 25902 thru 25904 are used to denote the 

subject PFVL is used to query the Control Repository and Library Name, Library File Type and Version in which the 

store the Process Result and Message against the file being data permanently resides. If the file is currently in a private 

installed. Step 24941 interacts with the Process Manager to library, the user enters the name of the public hl)rary to 

Store the Result into the Control Repository. 5 which the file will be promoted to in the future. Drop down 

Eventually, Step 24942 is invoked to test for the Part menu buttons 25907 can be used to display a list of all the 

Number Option This option is used to store PIN information known public b*braries in the DMS. Button 25908 will 

against the subject file. If this option is passed. Step 24943 display a list of the valid Library File Types used in the 

is called to Read the Part Number File which contains the library. Likewise, button 25909 v^all show all valid Versions 

Part Number, the File Name and PFVL for whom the Part lO for the given Ubrary. If no library name is entered, then 

Number belongs, and the owner of the P/N. The program clicking on either button 25908 or 25909 will produce an 

loops through the Part Number File until it finds an entry empty selection list 

whose File Name and PFVL match the subject file. Step Field 25905 represents the Starting Level for the library 

24944 is then employed to interact with our Release Control search engine to conduct the search. This doesn't mean the 

Manager, to Assign the Part Number information into the 15 file must exist at this Level, it's simply where the user 

Cbntrol Repository. desires the search to begin. This can be any valid Level 

Note: In the case of a High Performance install, the associated with the Library entered in field 25902, or it can 
subject file referred to in Steps 24935 through-'24SM4'Would be the keyword -user. This keyword instructs the search- 
actually be all files in the High Performance File List whose engine to first in^ct the user's private library for the file, 
names and PFVLs match those listed in the Results, Resolve 20 If it's not found there, then the search engine should traverse 
and Part Number files. the library structure beginning with the Entry Level denoted 

Finally, Step 24913 is executed in the event that a Process by field 25906. Drop down menu button 25910 can be used 

Queue entry requires clean-up. If the install request was to acquire a list of all available Levels for the Library, 

received firom an ALM other than the current ALM, then the Version, and Type entered in fields 25902 thru 25904. One 

sending ALM set an entry in the Process Queue. That 25 of the dioices is always the keyword user. 

Process Queue Reference number is induded in the install The Entry Level field, 25906, serves two purposes. The 

request, and is used to remove the entry from the queue. In first is to provide direction for the library search engine in 

addition, if the Process Phase is a Pre-Process, and any part the event that field 25905 indicates user, but the file is not 

of the algorithm failed to complete successfully, then a found in the user's private hbrary. In this case, the search 

special entry is added to the Process Queue to prevent any 30 engine will begin at the level entered in field 25906 and 

subsequent Library Processes firom executing against the traverse through tbe library strucnire until the file is located, 

source files. In addition, the source files are prohibited from The second purpose is to determine which level the Update 

moving through the DMS until the install can be success- Lock is to be associated with. Our embodiment permits 

fully retried. multiple users to bold Update locks on tbe same file, but at 

File Check Out Utility 35 different entry points into the DMS. Button 25911 displays 

Our embodiment permits the user to request ownership of a list of all valid Levels for the given Library, but unlike field 

any file in the DMS and associate that ownership with an 25905, the keyword user is not permitted, 

entry point into the library. This concept of ownership by The algorithm for checking data out of the library begins 

entry point allows a sophisticated environment to exist with Step 25951, SLL= User. Here the Starting Library Level 

where one owner can modify data at one level, promote the 40 entered in field 25905 is checked to see if it's the User Level 

data to a higher level, and a second owner can make further of a private library. If so, the user's private library is 

modifications. The DMS Architecture also permits a user to examined to see if die User File Exists in Step 25952. If so, 

set Update Locks at non-entry Levels, or set locks on ALL the Lock Check subroutine illustrated in is invoked and the 

Levels which prevents another user from modifying or program complete s. The Lock Check routine is discussed in 

moving the file. However, these actions are not part of the 45 greater detail later 

File Ctrcck Out Utility and must be performed through a lock If the file doesn't already exist in the User's private 

setting utility in the Lock Manager. Ubrary, then the SLL Library Search is employed. The 

The user is also given the option to physically copy the standard Ubrary search engine is used to seek out the most 

file from a public Ubrary into their private library. The entire recent copy of the file starting at the User Level. The search 

operation suns in the user's environment without the aid of 50 engine also uses the Entry Library Level entered in field 

an Automated Library Machine. The request will be honored 25906 of to direct the search through the proper entry point, 

or rejected depending on the current state of ownership and If no file is found, the user is asking for an Update lock on 

the relationship of the user to the current owner. The user a non-existent file which is an error condition that terminates 

initiates the operation with the File Check Out menu. the program. At the conclusion of the search the user is 

The preferred embodiment presents the user screen in a 55 shown the sohition of the search. The Lock Check subrou- 

graphical environment where the user engages pull down tine is again used to establish an Update lock. Upon return 

menus, pop-up menus, drop-down lists, radio buttons, push from the Lock Check routine, Step 25954, File Copy, is 

buttons, fill-in fields, and mouse interaction. It should be invoked. The program asks the user for permission to copy 

noted, however, that all fimctions discussed further in the the file from the library Level into the User's private Ubrary. 

preferred embodiment can be implemented using simple text 60 The file is renamed to tbe SLL, which is user in this case, and 

screens^ or more advanced data entry systems such as touch the program completes. 

screens, voice commands or 3-D graphics. The preferred Returning to Step 25951, if the SLL is not the User level, 

embodiment depicts the method most conducive to the it's assumed to be a valid Level for the Library, Library File 

Motif™, Windows''^, and OS/2™ application environ- Type and Version entered on the menu. This Starting Library 

ments. 65 Level is used to initiate the library search engine. Upon 

The screen contains six data entry fields, labeled 25901 completion of the search, the solution to the search is shown 

thru 25906. Field 25901 is wl^re the user types in the name to the user. The Lock Check subroutine is invoked, and upon 
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return, Step 25955 is employed to see if the Starting Library buttons, fill-in fields, and mouse interaction. It should be 

Level File Exists, If not, Step 25954 is again invoked to cx)py noted, however, that all functions discussed further in the 

the file to the user's private Library and rename it to the preferred embodiment can be implemented using simple text 

Starting Library Level The user is given the opportunity to screens, or more advanced data entry systems such as touch 

confirm this operation. 5 screens, voice commands or 3-D graphics. The preferred 

If a file aheady exists with the same Starting Ubrary embc>diment depicts the method most conducive to the 

Level, the program indicates this to the user, in Step 25956, Motif™, Wmdows™, and OS/2"- applicaUon cnviroo- 

by showing the solution of the search along with the file in '°^5f*' , ... 

,/ ..e^r'o i;Kr««, .,^^r rr^w^r, tuZ ^^r..H,r^uxi to Tfac screcu contams fivc data cuiTy fields, whicfa could bc 

the users library. Ine user is given the opportumty to i . i j ^t»^tt .t. t^- u ^m^* • i_ ai. 

1 . , p,. ^ J. labeled 28211 thru 28215. Field 28211 is where the user 

replace the pnvate «>Py of the file with the hbrary copy If 10 ^ ^^^^ 

ttie user accepts i^ the file is copied and renamed usmg the indirectly or leave it blank to generate a selection list which 

Startmg Library Uvel If the user rejerts it, the program ^^^ ^^ ^^^^^^ Pj^l^ 

termmates with the end result bemg an Update Lock set on 28212 denotes the Library where the file(s) reside. This 

the existing file m the pnvate h-brary. function is only intended for data tracked in a pubUc library. 

Turning to the Lock Check Subroutine, the algpnthm 15 therefore this field must contain the name of a valid public 

begins with Step 25960 which calls upon the QRSUPGET to library. Drop down menu button 28216 can be used to obtain 

return all the lock and authority information about the file. a list of all the public libraries in the DMS. 

-Next, Step 25961, ELL-Lock-examines these locks to see if ^ Fields 28213 thru 28215*are used to enter the Library 'File- • 

any are owned by someone other than the user. If so, these Type, Version and Level where the file(s) reside. Button 

other locks are displayed so the user can see who else claims 20 28217 will display a list of the Library File Types used in the 

ownership of the file. If another user has any ownership Library, button 28218 will show all valid Versions and 

locks (at the same or different level), the user is given the button 28219 will display all valid Levels. This information 

opportunity to abort the chedc out. In addition, the user is is used to initiate a library search for the file ^ccified in field 

also notified whether they have the proper authority to 28211. In the event the file doesn't exist at the specified 

promote this file into the desired Entry Library Level. 25 Level and Version, a dialog box will display the closest file 

If a lock exBts for the Entry Ubrary Uvel. it's checked ^ library search. The user is given the opportunity 

in Step 25962 to sec if the User Owns It If so, the user ^ a?^<^P{ "^Jf T"""^ vu ^ u 

officiaUy owns the "key" to this "entry door" and the routine ^^^^ \ ^^^^^""^ ^^^^g ^^^^ hbrary search 

passes ojntrol back to the main algorithm User Surgte, is ^! ^ ^P^^^^^ "^^^ ^^^^^ ^ °^^y ^ 

invoked. Here, tfie database is queried to see if the user is a 30 ^^^^^ ^ ^^^^ 

vdid surrogate for the cunenl owner of the ^ Number or Problem Fix ControUhe user can expUcidy 

the user is told why the lock can't be set m their favor and ^^^fy Level and/or Version of the previous file which 

the program termmates. Ifthe user is a valid surrogate, then ghoukl be used to reassociate the Part Number and/or 

Step 25964, Reset/Notify is employed. In this step, the user reactivate the Fix Management data. The Level and version 

is told who currently owns the lock and is given the 35 are entered in fields 28220 and 28221 respectively. These 

opportunity to take ownership. If the user accepts it, the fields are optional, and if left blank will cause the Fore- 

DMS sends a notification to the previous owner indicating ground process to interact with the user to obtain the 

that the user has now taken ownership of this entry point. information. Drop down menu buttons 28222 and 28223 can 

The routine returns control to the check out algorithm. be used to show a list of valid Levels and Versions for the 

Returning to Step 25961, if 00 Update lock corresponding 40 corresponding Library, 

to the Entry Library Level exists, then an Entry Library The only option for this operation is the Model option 

Level Lock is Set in Step 25965 for the user. This is done via which the user can specify via push button 28224. This is the 

interaction with our various Loch. Manager functions. means by which the user acknowledges that deletion of the 

At this point the program returns control to the main file will cause either Bill of Materials deletion or invafida- 

algorithm. 45 tion. 

File Deletion Utility Returning to the overall flowchart, information entered in 

Since data integrity can be easily compromised by uncon- Step 28101 is now passed to Step 28102, Foreground 
trolled file deletion, our embodiment provides a robust Processing. The detailed algorithm for generating file dele- 
utility for deleting data in a safe and orderly manner. It also tion requests begins with Step 28311, Parse Opts. Here all 
ensures that the control information such as Problem Fix 50 the options are examined to ensure they are recognized and 
Numbers and Part Numbers are correctly handled. The the values are acceptable. If Previous File Info is passed as 
preferred embodiment depicts the overall flow of the delete an option, the values are checked to ensure they exist for the 
or data removal. given Library. 

The flow begins with Step 28101, Entry Screen, where the In Step 28312, a File Loop is initiated in the event the user 

user is presented with the File Deletion Screen. This screen, 5S selected multiple files from the user screen in Step 28101. In 

permits the user to enter information about the file(s) they this case each file must be subjected to the same checks and 

wish to process. In Step 28102, Foreground, the information tests since each file possesses individual characteristics, 

gathered in Step 28101 is processed and additional infor- The next series of steps pertain to handling Bill of 

mation may be requested. Some basic checks are performed Materials (BOMs), if they exist Beginning with Step 28313, 

before passing control to Step 28103. In Step 28103, 60 Model Opt, the program tests the Model Option flag. If this 

Background, our preferred embodiment processes the flag is true, it indicates the user accepts the possibility of 

request on an Automated Ubrary Machine since these are BOM Deletion or Invalidation and does not wish to be 

the only users with the proper pennission to edit or delete warned in advance of the consequences. One example is the 

data within the DMS. act of deleting a file which is an anchor to a BOM. If the user 

The preferred embodiment presents the user screen in a 65 knows this in advance, they can pass this option to avoid 

graphical environment where the user engages pull down uimecessary checks. In this case control proceeds to Step 

menus, pop-up menus, drop-down lists, radio buttons, push 28317. 
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However, if this option is absent. Step 2^14 is invoked 
to check for BOM Deletion. Here, the Control Repository is 
queried to see if the current file is a BOM. If so. Step 28315, 
Warn User is employed to notify the user of the impending 
BOM deletion. The user is given an opporttmity to abort the 
process. The next step, 28316, queries the repository for any 
BOM Invalidation. This tests for the situation where the 
current file belongs to some other BOM, so its removal will 
result in a BOM becoming invalid. Our Aggregate Manager 
is used to quickly locate any BOMs in the DMS which 
contaio this file. 

Once again, if an invalidatioo will occur. Step 28315 is 
employed to notify the user and give them the chance to 
abort the deletion. 

Regardless of the setting of the Model Option flag, control 
eventually proceeds to Step 28317, File Check. In this step, 
the algorithm queries the database to ensure the file exists in 
the Control Repository and the repository agrees on the 
"-Level and Vsrsion. If the-Level and Vbrsion'ictumed'bythe 
Control Repository are not identical to that indicated by the 
user in Step 28101, an error occurs which notifies the user 
and aborts, the program. 

The algorithm proceeds to Step 28318 where the Part 
Number and Fix Management Flags are obtained fi-om the 
Control Repository and examined for the Library File lype 
being processed. If the LFT is under Part Number Control, 
Single Fix Tracking or Engineering Change Mode, control 
proceeds to Step 28319. In Step 28319, PN/FM Info, all Part 
Numb^ and Fix Management information is obtained for 
the file being processed. In addition, all obsolete files, of the 
same name, and at higher levels, which are attached to the 
same part number and/or attached to the same EC Number 
are also returned. 

At this point the algorithm determines which dormant file, 
if any, will be used to reassociate the Part Number and/or 
reactivate the Fix Management information. First, the Pre- 
vious File Info fields 28220 and 28221 are examined in Step 
28320. If the user specifies a particular level or version, they 
are expecting the corresponding file to be used to reassociate 
the PN and/or revalidate the problem fix numbers. In this 
case, the program employs Step 28321, Locate Previous 
File, to sift through the data returned in Step 28319 in search 
of the expected file. If the file is not in the list, it's an error 
condition and the program terminates. Assuming the file 
exists, the program proceeds to Step 28322, Trap PN/FM 
Info. In this step, the algorithm sets a flag and remembers all 
the information necessary to disassociate the old Part Num- 
ber and Fix Management data fi-om the file about to be 
deleted. It also captures the information about the file 
selected for re-association. Although the information is 
captured, the actual updating of the Control Repository is 
done in a later step. 

If the ftevious File Info fields are empty, the programs 
checks to see if the list returned in Step 28319 only contains 
a single entry. If so, Step 28315 is invoked to warn the user 
that the file in the list will be the one used for PN/FM 
rcassodation. It also provides an opportunity to abort the 
process. If the user accepts this. Step 28322 is employed to 
capture the information. 

The last possible case for PN/FM re-association. Step 
28324, involves a list with >1 File being returned in Step 
28319. If this is the situation and do Previous File Informa- 
tion is provided, the program uses Step 28325 to present the 
user with a Selection List Tlie user may select only one entry 
or abort the operation. Assuming one is selected. Step 28322 
is invoked to capmre the information. 

If the Part Number and Fix Management Flags in Step 
28318 are off, or no files were returned in Step 28319, or any 



i0,201 

56 

PN/FM information was trapped in Step 28322, control 
proceeds to Step 28326. In this step, the Level of the file 
being deleted is checked to see if it's a Release Level This 
includes active or frozen Release or Sideways Levels. If the 
5 Level is any of the aforementioned types, Step 2831S is 
invoked to warn the user and provide an opportunity to 
abort. 

Control eventually proceeds to Step 28328, PN/FM 
Re-assoc. In this step, the algorithm uses the information 
trapped in Step 28322 to interact with the Control Reposi- 
tory. It eliminates all Part Number information associated 
with the file about to be deleted, and reincarnates all Part 
Number information pertaining to the file found in the 
previous step. In addition, the superseded Problem Fix 

J J nimibers attached to the file arc converted to an active state. 
All appropriate Part Number and Fix Management tables 
within the repository are updated to reflect a state whereby 
the previous file assumes the role of the file being. deleted. 
At this point, control returns to the top of the File Loop 

^ in Step 28312. Once all files have been processed through 
Steps 28313 thru 28325, control proceeds to Step 28329, 
list Files. Here the Filenames, Library, Level, Version, 
Library File Type, and File Reference numbers are written 
into a Library Delete list which will be transmitted to the 

2j Automated Library Machine in the next step. 

In step 28330, Xmit, the program gathers and transmits all 
of the necessary data to the Design Control System. In our 
preferred embodiment, the destination would be an Auto- 
mated Library Machine which would "receive" the infor- 
mation fi-om the user via an AutoReader The following 
information need to be transmitted in the delete request: 
The type of request: Delete 

The list of files being promoted. The following infonna- 
tion must exist for each file in the list: 
35 The Filename 

The Library File Type 
Hie Padcage 
The \^rsion 
The Level 

40 Any user selected options that pertain to the background 
operation. 

The user's electronic id or e-mail address. 
This file is transmiUed to the ALM for use in the Back- 
ground Processing step. 

45 Returning to the overall process, the foreground informa- 
tion in Step 28102 is transmitted to an Automated Library 
Madiine for background processing. The detailed algorithm 
for Step 28103, Background, begins when the algorithm 
enters a File Loop, in Step 28411, where the list of files 

50 transmitted from the Foreground are processed into a data 
structure. Each step in this algorithm must be performed 
against every file in the list. 

Step 28413 obtains the Lock Information for the file from 
the Control Repository. This includes information about 

ss every possible lock the file possesses at any Level within this 
Version. In the subsequent steps, the list of locks are 
examined and different actions are taken depending on the 
types of locks in existence. 
Step 28414 checks to see if any Processing Locks exist on 

60 the file at the specified Level. This would indicate a Library 
Process is currently dependant on the existence of the file, so 
Step 28415 is invoked to Recirculate the delete request. la 
our preferred embodiment this entails re-writing the delete 
request file with the names of all the unprocessed files, and 

65 sending it back to the main queue of the DMS. In a simple 
system without Automated Library Machines, the necessary 
action would be to introduce the request back into the DMS 
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queue or inform the user to try again at a later time. At this 
point the processing is complete. 

If no processing locks exist. Step 28416 checks for Move 
or Overlay Locks at the Level where the file exists. In either 
type exists, Step 28420 Sends an Error Message to the user 
indicating that the file can't be erased. The program termi- 
nates after the notification is sent. 

If no Move or Overlay Locks exist the program proceeds 
to where Step 28417 examines any Update Locks that exist. 
In this step all Update locks are examined regardless of the 
Level. In Step 28418 a determination is made as to whether 
the User Owns All the Update Locks If this is true, then the 
user is the official owner of the file according to the rules of 
the DMS. In this case, control can proceed to Step 28421. 

If there are some Update Locks which the user doesn't 
own, or no Update Locks exist at all, then the program 
checks to see if the user is the Package Manager or Alternate 
-in Step -28419. As long as the user is the^Data-Manager or 
a valid alternate, the program is allowed to proceed to Step 
28421. If the user is not a Data Manager, Step 28420 is 
invoked to send an Error Message indicating the situation, 
and the program terminates. 

Assuming that the user meets one of the authority criteria, 
cootrol proceeds to Step 28421 where the File is Checked to 
ensure the Control Repository agrees that it exists at the 
specified Level and Version, and ensure the file doesn't 
reside in a frozen Release Level. 

Next, the algorithm checks the Fix Management Flag in 
Step 28422. This consists of querying the Control Reposi- 
tory to see if the FM flag eidsts for that Library File Type. 
If so. Step 28423 is invoked to Delete the Fix Management 
Information pertaining to the file. This is done via our Fix 
Management routines. 

Step 28424 performs a similar function with the Part 
Number Flag The repository is queried to see if the PN flag 
exists for the LET being processed. If so. Step 28425 is 
implemented to Delete the Part Number Information per- 
taining to the file. This is done via our Part Number routines. 

At this point control is passed to Step 28426 to Delete the 
Lock Information pertaining to the file. This is done via our 
Lock Management routines. If the user is a Data Manager, 
it is possible for the file to be in a completely unowned state. 
In this case, the DMS will not abort, but will continue with 
the next step. 

In Step 28427, the QRFILDEL routine, described in FIG. 
11, is employed to Delete the File from the Control Reposi- 
tory. This entails updating the necessary files tables to 
eradicate any associated entries. 

Steps 28428 thru 28430 are designed to handle any Bill of 
Materials associated with the file. In Step 28428, the DMS 
checks to see if the file itself is the anchor file of a BOM. If 
so, BOM Deletion will occur for all BOMs associated with 
the file. Step 28430 is invoked to Notify the owners of all the 
BOMs about the elimination. BOM deletion is Performed 
via our Aggregation Management routines. 

In Step 28429 the DMS checks to sec if any BOMs are 
Invalidated by the removal of the file. If so. Step 28430 is 
again invoked to notify all owners of any affected BOMs. 
BOM invalidation is performed via our Aggregation Man- 
agement routines. 

The last step in the File Loop is Step 28431 which will 
Erase the File. This includes obtaining the physical location 
of the file from the Control Repository and performing the 
deletion. Depending on the enviroiunent, the Automated 
Library Machine may have the proper permission to perform 
a direct removal, or it may have to transmit a request to an 
agent which is capable of performing the removal. In our 
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preferred embodiment, the method of removal depends on 
the ALM configuration employed. In a Conventional System 
or any arrangement nmning on a Unix/AIX platform, the 
ALM can delete the file without assistance. However, in an 
5 Actor/Object configuration running on a system such as VM, 
or a complex system involving multiple computer platforms, 
the ALM may need to request the Object to perform the file 
removal. 

Control returns to the top of the File Loop in Step 28411 

10 until all files in the request are processed successfully. The 
operation then exits with a success message sent to the user. 
Automated Library Machines (ALMs) 
Our embodiment contemplates the use of Automated 
Library Machines (ALM) to process the work requests on 

15 behalf of the users. Although this embodiment is ideally 
suited for the various process and methods described in the 
other sections of the Inferred Embodiment, ALMs are not 

' confined to mnning only those processes.* AlMs may exist 
in Data Management Systems running processes and algo- 

20 rithms outside of those mentioned in this disclosure. 

Our embodiment employs an Automated Library Machine 
(ALM) to service data management requests on behalf of the 
users. This enables the user to initiate a library job such as 
promotion request. Designer Initiated Library Process, or 

25 delete request without requiring significant client resources. 
The ALM provides continuous service by utilizing the 
concept of a reader to queue and prioritize users' requests. 
Performance of the Cbntrol Repository may also benefit 
since the most of the communication is with a relatively 

30 small number of ALMs compared to the larger number of 
individual users. 

The preferred embodiment uses ALMs to execute all the 
Background algorithms included in the embodiment One 
skilled in the art would appreciate that an alternate embodi- 

35 ment doeso 't require ALMs by eliminadog all the transmittal 
steps in the various Foreground algorithms, and simply 
running the Background algorithms on the client machines. 
As eluded to above, this may require substantial client 
resource and may compromise performance of the Control 

40 Repository. 

For large Data Management Systems, our embodiment 
permits the creation of multiple ALMs to service a single 
library. This enables large user groups to redeem faster 
results through the use of parallel processing. The Data 

45 Manager has the option of arranging the pool of ALMs in 
one of three configurations depending on the expected type 
and volume of data management requests. The basic con- 
figuration is known as a Conventional System where a single 
ALM accepts all work requests and bandies all services for 

50 the Library Manager, including any Automated Library 
Processing. The second configuration is Remote Execution 
Machines which is an extension of the Conventional Sys- 
tem. Here, a single ALM receives all work requests from the 
user, and processes all promotion, installation, movement, 

55 and removal of data. However, additional ALMs may exist 
to perform Automated Library Processing. The ALMs inter- 
act with the Library Manager, Communication Manager and 
Promotion Algorithm to dispatdi any desired library pro- 
cessing to a Remote Execution Machine* which executes the 

60 task and returns the results to the master ALM. The most 
powerful configuration is known Actor/Objects and this 
arrangement employs a pool of ALMs which serve as 
general purpose machines. They can perform any desired 
Library Management function, including Automated Library 

65 Processing. They can even interface with Remote Execution 
Machines to provide an environment widi both general 
purpose machines and dedicated service machines. Each 
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Actor can be programnied by the Data Manager to define the function and sends a completion message to the Actor. If 

type of work requests it can process. This arrangement even either the Actor or Object fails to transmit or respond to a 

includes a special Dispatcher ALM whose sole purpose is to message successfully, a mechanism will resend the message 

dispatch user work requests to the next available Actor until the handshaking is complete, 

machine. 5 Regardless of the environment, all Actor/Object systems 

The means by which data is physicaUy moved between, support the following functions: 

added to. or deleted from, the repositories depends on the Rename Move or Rename the file from the source to the 

chosen configuration. In a Conventional System, the primary location. This is only used on environments 

ALM is the only ALM with the proper authority to manage "^^^^^ support it such as Unix/AIX, or VM when the 

files on any repository within its own library. Remote lO source and target are the same minidisk. 

Execution Machines may only receive work requests and Copy Copy the file from the source to the target location, 

return data and results to the Primary ALM. Our embodi- This is used to install an output file from an Actor into 

ment does not permit Conventional Systems to process file repository, or as the first part of promotions involv- 

transfeis across multiple platfoims. i°g ^ Cross-Platform file movement, Cross-Account or 

Id this system, all actions are initiated by job requests. 15 Cross-Minidisk file movement on VM. 

These may be include: Delete Delete the file from the source location. This is 

Qass A: Requests to promote data from a user's private ^^^ed for File Delete requests or as the second part of 
—library into the public library' or invoke Designer "Ini- promotions involving a Cross-Platform file movement, • 

tiated Library Processes. Cross-Account or Cross-Minidisk file movement on 

Class B: Requests to promote data through the public „ ^^1, ^ ^ , . ^ ^. . . , . . . , 

]^j^jy Batch Used for multiple files which must be manipulated 

^ ^ I, jwM,^. ^ of the sanac task- Abatch file is generated listing 

asss C: Requests for Automated Library Processing on a ^ ^^.^ corresponding command line. 

Remote Execution Machme or responses from Remote oommandte must be one of the three supported 

Execution Machmes to mdicate completed Library commands (Rename, Copy or Delete). The ALM toops 

through each line of the batch file atxi Processes each 

Qass D: Requests to install new data generated by file successively. 

Library Processes on Remote Execution machines. Note: ALMs only deal with file manipulation requests. In 

delete files from the DMS, or perform Data Manage- the preferred embodiment, it's up to the DMS algorithm 

ment functions. 30 overseeing the file movement (sudi as the Promotion or File 

The classes represent priorities with Qass D being the Installation algorithm) to determine which type of library 

highest and Qass A being the lowest. Every ALM in the arrangement exists and whether job requests should be 

library (Primary ALM and all Remote Execution Machines) created and transmitted to a Conventional ALM or Actor/ 

runs the ALM algorithm as an AutoReader task. AutoReader Object commands should be generated and executed, 

automatically invokes the algorithm whenever a file is 35 Therefore, the underlying code for all these algorithms must 

received in the reader. query the DMS for the type of library arrangement. If it's 

In an Actor/Object system, either the Actors have the Actor/Object, the code must also determine whether the 

ability to directly manipulate files in the repositories (such as environment utilizes an Actor/Object messaging scheme, or 

Unix/AI>Q, or they must rely on a dedicated ALM known as whether the Actor can execute the Rename. Copy and Delete 

an Object to handle all file management tasks. The Object 40 functions directly. 

has the proper authority for all repositories in the library. The Automated Library Machines are based on the concept of 

Actors run the ALM algorithm as an AutoReader task, just an Automated Reader where the Reader is a temporary 

like the primary ALM in a conventional system. However, storage area which accepts library requests, A Reader may 

many of the Qass C and D jobs related to file management simply be a directory where data is copied into, or it may be 

are replaced by the Actor performing its own file manipu- 45 part of die environment such as the VM system. Asimplistic 

lations (if the environment allows it), or by communication implementation of an Automated Reader would incorporate 

with the Object (such as a VM Actor/Object system). a continuous loop with a timer to view the files in the Reader 

In systems requiring an Object, communication between at specified intervals, and upon finding one, initiating the 

the Actor and Object is accomplished by an asynchronous aLM algorithm. However, our preferred embodiment 

messaging system where the Actor initiates a request to the 50 implements an Automated Reader by using an AutoReader 

Object and waits for a response message from the Object. service machine. This software machine is capable of per- 

The message consists of a command line which includes the: forming many tasks outside the arena of Data Management, 

Function to be Performed as well as providing the Automates Reader function. 

Source File Name Once a file is detected in the Reader, the ALM algorithm 

Source File Tirpe ^ invoked. It begins with Step 29120 where a registration 

Tar et File Name check is performed. All ALMs must be registered with the 

^ Control Repository, and when registration is complete a flag 

Target File Type ^ ^ Step 29120, Reg, Hag, this flag is tested to ensure 

Source Repository it's set. If not, Step 29121 is invoked to Register the ALM. 

Target Repository 60 The ALM is first checked to ensure it's an authorized user 

The repository fields include enough information to of the Control Repository, and if so, it updates the repository 

physically locate the file regardless of the platform or with certain environmental information such as user id, 

environment. The Object, in turn, runs a continuous routine system address, etc. i 

implemented as an AutoReader interrupt hook. Whenever it Upon completion of the registration, Step 29122 is 

receives a message^ the routine 'Svakes up" and checks to 65 executed to test for a Startup command. This is passed into 

ensure the message is from a valid Actor, and contains one the ALM algorithm as an AutoReader parameter whenever 

of the supported functions. It then executes the appropriate the machine is re-started. This could be the result of a system 
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crash or a manually initiated command. In the case of an multiple files contain the same priority, they are sorted by 
ALM Startup, various tests are made to attempt to recover time from oldest to most recent. This yields the oldest, 
any interrupted or incomplete tasks. The first test, done in highest priority file. The program then determines if the type 
Step 29125, is for a Process Crash. This is done by looking is a library request. If so, it will be processed, otherwise, the 
for the existence of a Bucket in the ALM's work space. Our S sorted list is searched until the oldest, highest priority hl^rary 
Process Manager writes a Bucket file each time it begins request is found. This ensures that the library requests are 
running an Automated Library Process. If the process com- done in the proper order, but still permits non-library work 
pletes normally, the Bucket is erased. The existence of a to be intermixed. 

Bucket signifies a Mid-Prooess crash, which results in Step Next, Step 29124 is invoked to Resolve the Sender of the 
29126 being executed to Send a Message to the user who lO library request. This entails reading the sender's id and 
requested the Library Process. This information is contained electronic address from the header portion of the work 
in the header of the Bucket file. request At this point control proceeds to a Receive the File. 

Control proceeds to Step 29128 to test for a Create DILP Receiving the file refers to moving the file from the reader 
Recovery file. This file is created during the installation of to the ALM's workspace so downstream programs can 
the output of a special Automated Library Process known as 15 access it. These downstream programs may be the Promo- 
a Create DILP. In the event of an ALM interruption, this file tion algorithm or an Automated Library Process, but our 
contains all the information necessary to retry the file embodiment ensures all ALM's use identical work spaces, 
installation. Next,-Step 29129 checks forthe File Existence which are environment specific, so anydownstream process- 
of the Create DELP output. Assuming it's present in the can easily find the data. For example, in an aix/unix 
ALM's work space, Step 29130 in invoked to Automatically 20 environment, a nomeoclated subdirectory is used as the 
Retry the installation of all Create DILP output. The instal- ALM's work ^ace, whereas temporary DASD is used in a 
lation entails calling the QRSUPGEN function to update the VM system. 

necessary files tables as well as calling QRRESADD to add Steps 29146 through 29163 are used to direct the library 
the Library Process result. request to the proper algorithm. It can best be handled with 

The third test is for a regular Install Crash in Step 29132. 2S a case or select statement, and the don't imply any order for 
Hiisisacoomplishedby testing for the existeiKX of an Install these steps. Step 29146 tests for a Report Request. Our 
Recovery file. Like the Create DILP Recovery file, this file embodiment permits the user to send requests for various 
is written as part of the file installation algorithm to aid in nightly reports. If Step 29146 tests positive, then Step 
automatic recovery. If it exists, the recovery action is deter- 29147, Rpt is invoked to add the request to the nightly report 
minedby the existence of the Process Phase parameter in the 30 queue file. At a pre-detennined time, a service machine 
Install Recovery File. Step 29134 tests for the Process wakes up and processes all the requests in the queue. 
Phase. If it is absent, the installation was not initiated by an Step 29148 tests for a Promote Request. These can be 
Automated Library Process, therefore Step 29136 simply requests to transfer data into a public library from a private 
Recirculates the Install Request. If the phase does exist and library, or move data through a public library. The data may 
the originator of the request is an ALM other than the current 35 be an individual file, a group of files, or an aggregate 
machine, then Step 29138 is executed to test if the Phase= grouping. Regardless of the type of promote, control is 
Pre Process. If so, then Step 29140 will be invoked to call passed to the Promotion algorithm in Step 29149. This 
the QRPRQADD function to add a special entry to the algorithm is detailed in FIGS. 14 and 15. 
Library Process Queue. This prohibits the file undergoing Step 29150 tests for a Delete Request. These are requests 
Pre-Processing from moving through the DMS, or executing 40 to delete data from a shared hl)rary, and they can be initiated 
any further Library Processes, imtil the installation can be by the owner of the data or the Data Manager. Delete 
performed successfully. Regardless of the phase. Step requests are handled by the Delete algorithm in Step 29151. 
29142, QRPRQDEL, will eventually be called to delete the The case structure continues with Step 29152 which tests 
entry from the Library Process Queue that was created by for an Install Request. This type of request originates from 
the Install Algorithm to prevent any file creation or move- 45 an ALM acting as a Remote Execution Machine in a 
ment while the installed file is in transit. Conventional Library System. Since the Remote Execution 

Once the appropriate recovery action is completed, or if Machine can only execute Library Processes, but not 
none of the three types of recoverable scenarios are satisfied, manipulate data, it must send a request to the Primary ALM 
control exits the algorithm and returns to the AutoReader to store the data into the repository. In this case, control is 
machine. 50 passed to the Install algorithm in Step 29155. 

Returning to Step 29122. if the current request is not a Step 29154 tests for a Store Request This is almost 
Startup then control proceeds to Step 29123 to Order the identical to the Install Request in Step 29152, except that the 
Reader. This step incorporates a combined algorithm to data is not tracked in the Control Repository. It's simply 
provide first-come-first-serve processing for non-Data Man- deposited into the data repository without any afGliation to 
agement requests, while ensuring Data Management jobs are S5 the library structure. These requests originate under the same 
handled in order of priority. First the file is examined to see circumstances as Install Requests, but they are handled by 
if it's possesses a higher priority than a Hbrary request. The the Store algorithm in Step 29155. 
type of request is also checked to see if it's a supported The Store Algorithm in Step 29155 simply consists of 
library request. All library requests contain a LIB keyword reading the file information out of the request file and 
in the job type. If none of these conditions are satisfied, the 60 determining exactly which repository the file should be 
program immediately returns control to the AutoReader stored on. This information is contained within the job 
algorithm to process the non-Data Management request. request Next, the code receives the file from the reader and 
Otherwise, tMs is assumed to be a library work request. In copies it into the appropriate repository. Since the file is not 
order to maintain data integrity, all library requests are tracked by the DMS, no queries are made to the Control 
processed in order of highest to lowest priority. Step 29123 65 Repository. Furthermore, the nomenclature on the file con- 
accomplishes this by sorting all reader files, which possess sists only of a Filename, Library File Type and Version, 
one of the four job classes, in descending priority order. If There is no Package, Level, or File Reference Number. 
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Id Step 29156, the program checks for one of the many their target locations. The code then executes the same steps 

types of requests associated with Automated Library Pro- in the Piomotioa Algorithm that would've taken place if the 

cesses. Due to the many different library arrangements source ALM performed the file movement. These consist of 

supported by our embodiment, any given ALM may be Step 22433 in FIG. ISd and all the steps in FIG. ISe. 
playing the role of a ConventioDal ALM, Remote Execution 5 If the request keyword doesn't match any of the tests, then 

ALM, or an Actor. This means that any ALM must be control is returned to the AutoReader and a message is sent 

capable of receiving a job request to initiate an Automated ^ sender indicating a nonsupported l&rary request. It 

Library Pre-Process, Post-Process, or a Designer Initiated should abo be noted that this structure easUy permits 

Library Process (DILP). Additionally, it may receive additional types of library requests to be added For 

restx)nses from comoleted Pre Post or DILPs AU reouests lo example, other OTVironments may require a type of library 
responses trom completed Pre, Post or DlLFs. AU requests lo ^^t discussed in the picfened embodiment. By 

related toLibrary Processing are handled by our Automated ^. ^ j/^^^^ 

^^J"^^^/ algorithm m Step 29157. ^^^^^^ ^ ^^^^^^^ ^^^^ 

Step 29158 is designed to handle requests which Create a request. 
Structure File. Our preferred embodiment uses Structure Qo the other hand, if any of the supported algorithms arc 

Files to supplement the Structure Tables in the Control 15 executed, they will eventually return control to Step 29170 

Repository. These files contain a formatted list of all the to test for a Processing Lock Some of the algorithms such as 

Levels and Versions installed for this Package, their the Promotion and Library Processing algorithms may not 

-^repositories, and^^the -^information* linking- the- Level- and — be able to process the current- request if it involves *^data"' 

Version tree. This permits many of the Data Management currently locked in the DMS. In this case, the algorithms 

fimctions to reference this file instead of queryii^ the 20 return a unique return code, which Step 29170 detects. If it 

repository, thereby increasing availability and possibly tests positively, then Step 29171 is invoked to Recirculate 

improving performance. In order to assure that these files are the request. This entails placing the request back into the 

kept in sync with the Cbntrol Repository, any changes made Reader with the same priority, but a current time stamp. It 

by the Data Manager to the library structure result in a there are no other work requests in the Reader, then this 

C^ate Structure File Request being sent to the library's 25 request will continuously loop through the Reader until the 

main ALM. Upon receiving it. Step 29159 is invoked to Processing Lock relieved and the appropriate algorithm can 

Update the Structure File usiqg the latest information in the service the request. 

DMS. This step extracts the structure information from the In a DMS utilizing ALMs, all Foreground algorithms 

Control Repository and writes it into the Structure File with transmit job requests to the ALMs which execute the Back- 

the proper format. 30 ground algorithms. In order to assist these Foreground 

The case structure continues with Step 29160 which tests algorithms in locating the proper ALM to send the request 

for an Authority Request. Data Managers may elect to use to, our embodiment provides the following means. The 

Authority profiles to generate a master list of authorized preferred embodiment contemplates the use of a Master 

users for their Package. Every time this list is generated, it's Library Directory which retains information about every 

sent to the master ALM for the Padcage, where upon 35 hbrary in the DMS. The listing is sorted by Package ID, and 

receiving it. Step 29161 is invoked to Replace the Autho- each record indicates whether the libraries for that Package 

rized Users List. This simply consists of copying the newly arc running in Conventional mode or Actor/Object mode, 

received file over the existing user list. Detailed information Additionally, the record indicates the primary repository for 

regarding Authority Profiles can be found in our Authority that library. This repository holds any data with library* 

Manager. 40 specific data such as Library Logs, AutoReader control files. 

Step 29162 tests for a Cross Platform data transfer sudi as Actor lists, etc. User data may or may not be located in this 

a file being promoted from a Unix/AIX platform to a VM repository. 

platform. Step 22432 of our Promotion algorithm, describes The Master Library Directory may be maintained within 

how files are moved fit}m the source repository to the the Control Repository or as a separate flat file kept in a 

destination. In many cases the ALM ruiming the algorithm 45 commonly accessible location. Since any authorized user of 

has the proper access to perform the necessary file transfer the DMS may invoke a Foreground algorithm, all users' 

functions without any assistance. However, cases such as client environments must have access to this information, 

this one, don't permit the proper access to the ALM on the Regardless of its location, the Foreground algorithms always 

source platform. Therefore, the source ALM suspends mn- follow this procedure for transmitting job requests. First, the 

ning the Promotion algorithm and uses a special ELM, 50 Package is checked to see if it's mnning a Conventional or 

running on the target platform, as a communication agent to Actor/Object system. If it's Conventional, then the primary 

forward a Cross-Platform job request to any ALM on the repository is the Primary ALM where all job requests should 

target platform capable of writing to the target repository. be transmitted. Using the four level Class system explained 

This ALM on the target platform receives the Cross- above, the Foreground algorithm directs the job request to 

Platform Data Transfer job request which requires the 55 the Primary ALM's reader queue. Eventually, the Auto- 

cial algorithm in Step 29163 to be invoked. Reader accepts the job request and initiates an ALM to 

Step 29163 runs the Cross Platform Algorithm, which process it. If the Foreground algorithm detects an Actor/ 

begins by reading the header line from the Cross-Platform Object system, then it must locate the Actor List. This is a 

job request file. Next a loop is establi^ed to process each listing of all the Actocs servicing a given library. For each 

file listed in the request. For each file the source repository 60 Actor in the list, information exists denoting the type of 

is linked in a read mode, and the destination repository is work requests it's allowed to receive. The Actor List is 

linked in a writable mode. The appropriate file transfer establi^ed by the Data Manager using our Data Manage- 

protoool is established and the file is copied to the target ment Configuration Utilities. A utility exists which permits 

repository. The copy of the file residing in the source the Data Manager to easily define a multiplicity of Actors 

repository is then deleted. 65 with their corresponding qualifications. Hiis information is 

At this point the file movement is completed, so control stored in the Control Repository and may be duplicated in a 

retiuus to the top of the file loop until all files are moved to text file which is stored in the primary repository. 
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Ooce the informatioa in the Actor List is acquired, the Here we will discuss how our preferred Design Control 

Foreground Algorithm looks for a special Actor called a Repository and System Methods can be used with varioiis 

Dispatcher In systems without dispatchers, the algorithm changes which need to be adopted for existing software in 

simply scans the Actor List until it finds an Actor capable of order to make use of that software in our new environment, 

accepting the type of work request being transmitted. If 5 In this area we will discuss the AFS environment. In order 

more than one woik request is being generated, and more to be used commercially in the future, we believe that the 

than one Actor is capable of accepting that type of work, the current software, now insufficient for our complex needs, 

requests are distnbutcd evenly between the Actors in a needs to be changed. Our PFVL structure and principles are 

simple round robin scheme. However, our embodiment adopted. 

incorporates the use of a Dispatcher to maximize efiBciency jq As one reads this, one will appreciate that we now have 

by receiving all work requests from all users into a single a data management system for file and database manage- 

"Bank Teller" queue. The Dispatcher is a special purpose ment which has a design control system suitable for use in 

ALM whose sole job is to accept work requests from users connection with the design of integrated circuits and other 

client machines, and dole them out to the next available elements of manufacture having many parts which need to 

Actor capable of servicing that particular request The be developed in a concurrent engineering environment with 

DispatcherALM runs a special Dispatching algorithm which inputs provides by users and or systems which may be 

is described below. Once the work request reaches the Actor, located anywhere in the world . Using our PFVL structure 

.it's hMdlcdJnJhe^same . nianner. as^a. .Conventional .System . . and process principles as the foundation for the architecture ^ 

whereby the request is received and processed by the ALM we provide a set of control information for coordinating 

algorithm. 20 of the design information through development 

Note: Work requests generated in the users' environment and to release while providing dynamic tracking of the status 

are never sent directly to Remote Execution Machines. The of elements of the bills of materials in an integrated and 

use of a Remote Execution Machine is specified for Auto- coordinated activity control system utilizing a control 

mated Library Processes by the Data Manager. When a user repository which can be implemented in the form of a 

initiates one of these special Library Processes, the work database (relational, object oriented, etc.) or using a flat file 

request is first analyzed by the Primary ALM, in a Conven- system. Once a model is created and/or identified by control 

tional system, or an Actor ALM. The ALM algorithm information design hbraries hold the actual pieces of the 

decodes the work request and calls upon our Library Process design under control of the system without limit to the 

Manager to direct it to the appropriate Remote Execution number of libraries, and providing for traddng and hierar- 

Machine. 3q chical designs which are allowed to traverse through mul- 

Our embodiment further enhances libraries arranged in an tiple libraries. Data Managers become part of the design 

Actor/Object configuration by contemplating the use of a team, and libraries are programmable to meet the needs of 

Dispatcher ALM. The Dispatcher is a special purpose Actor the design group they service. A control repository commu- 

which accepts job requests from the user and holds them nicates with users of the design control system for fulfilling 

until an Actor capable of processing that work request is 35 requests of a user and with data repositories of said data 

available to service it. Throughput is enhanced by ensuring management control system through a plurality of managers, 

all Actors arc kept busy whenever possible, and the woric- Each manager performs a unique function. Managers act as 

k)ad is balanced across all of them. Configurations using a building blocks which can be combined in a plurality of 

Dispatcher identify tbe userid in the Library's Actor List manners to support an environment for suitable for multiple 

with a special entry denoting it as a Dispatcher. All fore- 4Q users of a user community. 

ground algorithms which generate woric requests check for As we review our concepts in greater detail, it will be seen 

this entry upon detection of an Actor/Object configuration. that the present embodiment describes a Data Management 

If it exists, the job request is sent to the corresponding System (DMS) which is composed of a suite of function 

userid. Otherwise, the Actor List is examined for the first managers and one or more projects (see FIG. 16 — litems 10, 

Actor in the list capable of servicing that request. The job is 45 11» 14, 15 and 16). Each project is composed of a central 

then dispatched directly to that Actor If multiple jobs need Cbntrol Repository and one or more data repositories (sec 

to be dispatched, the jobs are distributed to all the Actors, FIG. 16— Items 12 and 13) to store, manage, and manipulate 

capable of handling the task, in a round-robin fashion. This virtually any type of data object. The Control Repository 

scenario may lead to an unbalanced workload among several consists of a Common Access Interface and one or more data 

Actors if the job requests have a large disparity in processing jq ^^^ses (see RG. 17— Items 1 thru 5). These data bases may 

times. The Dispatcher is designed to eliminate this. be: 

The preferred embodiment permits any ALM to act as a A Relational Data Base consisting of a collection of tables 

Dispatcher simply by configuring the Autoreader to run a of data where the columns contain the attributes of 

special Dispatcher algorithm. It works on the premise that related data and the rows are the instances of the data. 

Autoreader permits three types of interrupts: 55 An Object Oriented Data Base consisting of a collection 

1. A new request arriving in the Reader causes a PreCheck of object instances of classes where the attributes are 
intermpt. the class members. 

2. A message or command may be used as an interrupt. A Control File Data Base consisting of a collection of files 

3. AutoReader's built in timer acts as an interrupt when it where the records are the instances of data and the 
"wakes up". 60 attributes are ananged along the records. 

The algorithm continuously monitors for any type of A Directory Data Base consisting of a collection of file 

interrupts. Upon receiving one, it must check to see if it's directories which may or may not contain files. Their 

one of the three aforementioned types. There are other types .relationships are described by the directory structure, 

of interrupts, but they don't pertain to the Dispatcher func- The instances can be either sub-directories or files, 

tion. 65 This repository commimicates with users and the data 

Our preferred Design Control Repository and System repositories through a plurality of Managers, each perfbrm- 

Methods (5.0) ing a unique function. These Managers act as building 
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blocks which can be combined in numerous ways to support 
environments ranging from a small user conmiunity to a 
global enterprise. 

Our preferred embodiment employs a relational database 
to serve as the Control Repository. Each data object in the 
Data Management System (DMS) is assigned a unique 
identifier that permits all information about the object to be 
recorded and tracked by a multiplicity of relational tables. 
The physical data is stored using conventional storage 
management techniques which allow any type of data (text 
or binary) to be tradced in it's original form. The data may 
even reside on multiple platforms. 

Users of the DMS communicate directly with the Control 
Repository, through a Communications Manager, to initiate 
some or all data management functions. Upon initiation, the 
Communication Manager employs one of the other Manag- 
ers to complete the task. Our preferred embodiment con- 
templates the use-of' software service machiDes; known- as 
Automated Library Machines, which execute requests on 
behalf of the users. These Automated Library Machines 
(ALMs) automatically enable the proper Manager to carry 
out the desired task, while freeing up the user's environment 
to perform other activities. The Communication Manager 
also enables the ALMs to communicate directly with the 
Control Repository. 

In order optimize data storagp, our embodiment uses a 
PFVL paradigm to identify all data in the DMS by Eackagc, 
Eile Type, (Data Type), Version and Level. Packages are 
arbitrary divisions of data whereby all the data has some 
common association. A Data or Package Manager defines 
the structure for the Package and performs all data manage- 
ment administrative functions. Levels are typically associ- 
ated with "degrees of goodness" or quality. Data typically 
enters the DMS at low Levels with minimum entry criteria. 
As the quality improves, it is promoted to higher Levels until 
eventually being released as a finished product. Our system 
supports robust promotion criteria definitions which may 
exist for every PFVL in the DMS. Versions allow multiple 
variations of the same piece of data to be processed and 
managed simultaneously. One Version may be independent 
or based on another, ^ich eliminates the need for common 
data to be repeated. 

The present embodiment expands the PFVL paradigm 
into a means which enables the Data Manager to configure 
a Package under numerous structural arrangements. For 
example, the Data Manager may store all the data into a 
single physical repository, or segregate it by PFVL The 
structure may contain multiple entry points, which enables 
data to be Fast-Pathed into non-entry Library Levels. This 
feature supports unlimited branching where any Level may 
have multiple lower Levels, each of which may have mul- 
tiple lower Levels. Levels may be denoted Working Levels 
which constitute the minimum structure all data in a given 
Package and Version must traverse prior to release. Working 
Levels are transitory places v^ere no data resides perma- 
nently. In addition, our embodiment permits the existence of 
Release Levels where data resides upon release as a finished 
product. These can be Regular Release Levels where data 
may only enter from the highest Working Level and remain 
permanently frozen. There is also a concept of a Sideways 
Release Level which serve as a repository for modifications 
made to data residing in Regular Release Levels. 

In order to aid users and third party tools in locating data, 
our embodiment offers a Search Manager. The underlying 
utilities provide a means to search for data starting at a 
specified Level and Version. If the search fails to find the 
data at the starting location, it will traverse the structure 
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ascending Levels until all Levels in the current Version are 
exhausted. If the current Version is based on a previous 
Version, the search will traverse the previous Version. The 
search engine will locate data stored on multiple platforms 

5 and a single invocation can find multiple data objects of the 
identical or different data types. The Search Manager offers 
a multitude of options and features to seek out data in public 
and private Libraries, to sort and filter the results, and to 
perform the search with or without the assistance of the 
Control Repository. 

Our preferred embodiment describes the most sophisti- 
cated form of the DMS which incorporates a Commimica- 
tion Manager to manage all communications with the Con- 
trol Repository. It employs a series of communications 
machines capable of queuing and prioritizing queries initi- 
ated by users or Automated Library Machines. The mecha- 
nism enables unlimited access to the Repository regardless 
of the number of simultaneous queries supported by the 
database.^ Hie Comtnunication Manager al^ provides a 
medium of information exchangjB for all other Managers and 

20 the ALMs. Since the Communicatioo Manager supports 
multiple platfonns, it acts as an agent to provide remote 
access to the Control Repository through conduits such as 
the Internet. 

The present embodiment provides data control and secu- 
^ rity through a Lock Manager which offers three types of 
locks. First, there are Out for Update or Ownership locks 
which permit a user to check out a data object and modify 
it without fear of another user making a simultaneous 
update. Our embodiment also provides a means for trans- 
30 ferring ownership of a piece of data from the primary owner 
to a designated surrogate without the primary owner's 
intervention. Upon completion of the transfer, the primary 
owner is automatically notified of the ovraership transfer. 
Additionally, the preferred embodiment provides an envi- 
ronment where multiple users can own the same piece of 
data at different Library Levels. 

In addition to ownership locks, the Lode Manager offers 
Move and Overlay locks which can be used to prevent data 
from being moved through the DMS or overlaid by the data 
^ at lower Levels. It also interacts with the Aggregation 
Manager to provide locking of entire an Bill of Materials, 
and it interacts with the Process Manager to provide an 
interlocking mechani»n or data undergoing Automated 
Library Processing. 
*5 Our embodiment contains an Authority Manager to pro- 
vide various types of user authorities down to the PFVL 
granularity. Interaction with the other Managers affords, but 
is not limited to, the following authorities: 
Data Promotion into and through public Libraries. 
Bill of Material Promotion through public Libraries. 
Creation of a Bill of Materials 
Setting the three types of locks on data objects 
Initiating Automated Library Processes 
55 Setting Level Independent Pseudo Process results 

Our embodiment even permits pattern matching on the 
names of the data objects to add another Level of granularity 
beyond the PFVL. 

In order to aid the Data Manager in performing the 
multitude of administrative tasks, our embodiment contem- 
plates a Package Manager which includes utilities and user 
inter&ces to accomplish the following: 
Set up Package Control Data such as Fix Management 
and P/N Control Levels. 
65 Define or dynamically reconfigure the Library Structure, 
including selection of data types to be tracked under the 
DMS. 
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Define the physical repositories of the data (down to the 

PFVL if so desired). 
Balance workloads among Automated Library Machines. 
Define, manage and edit: 

Automated Library Processes 

Authorities 

Automated File Groups 

The Package Manager supports Authority Profiles which 
permit the Data Manager to assign users to a classification 
and apply authorities to the entire classification. It also 
incorporates the concept of pre-defined process groups and 
templates which allow process definitions to be standardized 
across multiple packages. In our preferred embodiment, 
these definitions can be stored in flat files caUed Progroups 
or within a sample Package in the Control Repository. The 
Package Manager also offers a variety of report gcrerators 
for information about installed Levels, \fcrsions, data types. 
Automated Library Machines; process definitions,- process 
results, authorities, fix management and release control 
information. Upon completion of all interactive editing, the 
Package Manager employs a batch commit process which 
converts the changes into a series of Control Repository 
modification instructions. 

Our Data Management System also employs various 
utilities to aid in performance tuning and automated recov- 
ery of the Control Repository, data archiving. Control infor- 
mation back-up, and a mechanism to generate performance 
tuning reports. 

Additionally the DMS employs a Library Manager to 
execute all data movement, check out, manipulation, check 
in and deletion. It also contains a Process Manager to 
provide Automated Library Processing and External Data 
Control. Also present is a Problem Fix/Part Number/Release 
Control Manager to associate and track problems and part 
numbers to data as well as coordinate releases. Finally an 
Aggregation Manager is included for creating and tracking 
arbitrary collections of data objects. 

Structure and Search Manager 

The present embodiment incorporates a robust concept 
which permits a data management structure capable of 
tracking a plurality of data objects governed under similar or 
disparate processes. The concept is based on a paradigm in 
which all objects can be classified by Package or its syn- 
onym Library, Type of Object (Our preferred embodiment 
denotes this as File Type), Version and Quality Level. This 
paradigm is hereafter referred to as the PFVL paradigm. (Sec 
FIG. 18 — litems 1 thru 7). Under this arrangement, a Pack- 
age is simply defined as a grouping of objects with common 
characteristics. In some environments, sudi as Chip Design 
or Software Development, a Package is referred to as a 
Library. Commonality may be defined in numerous ways. 
For eTcample, all the components in a Library may be 
members of the same higher level component (such as all the 
ASICs on a PC Board), and thus may be considered a single 
Package. Another example may be all the programming 
modules written by a particular software development team. 

Within a Package or Library, data is organized by Version. 
Versions allow parallel evolution of the same components to 
coexist in the same Library. For example, two Versions of a 
Video Graphics chip may be developed in tandem, one for 
the PCI interface and one for VL-BUS. Our embodiment 
allows the two flavors of design to use the same object 
names, reside in the same library, and even be at the same 
Level, simultaneously. 

For each Version, there is a Level Structure. In our 
preferred embodiment. Levels denote a degree of 
completeness, stability or quality control. The definition of 
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"degree of quality control" is left up to tl^ Data Manager. 
Our embodiment simply affords the Data Manager a means 
to establish a Level structure commensurate with the goals 
and objectives of the user community. 

5 All data objects are identified by name and type. Our 
preferred embodiment depicts all objects as files, but they 
can be any type of object that exists in a computer environ- 
ment. The type of object serves as the fourth qualifier in the 
PFVL paradigm. In summary, an entity characterized by a 
single name may have multq)le types of data objects, simul- 
taneously residkg in multiple Levels, of multiple Versions 
and spanning multiple Libraries. 

In addition to denoting degrees of completeness, our 
embodiment permits Levels to be chained together to allow 
data to migrate from one Level to the next. Any or all of 
these Levels can be designated as Entry Levels whereby data 
may enter from a user's Private Library. Levels are also 
categorized as Working Levels or Release Levels. Data in 

■ Working Levels is transitory, and must eventually migrate to 
a Release Level. Release Levels serve as permanent storage 

20 vaults for a coherent set of data. Once the data is promoted 
into a Release Level, that Level is frozen and a new Release 
Level is opened. Data always migrates from the highest 
Working Level into the cunent, or open, Release Level. Any 
Working Level may be promoted to from another Working 

25 Level, or serve as an Entry Level for data coming from a 
Private Library. Release Levels arc more restrictive. Hie 
current Release Level can be promoted to, but can't be an 
entry point for outside data. Frozen Release Levels are 
neither entry points nor are they promotable. Our embodi- 

30 ment does provide a means to thaw a frozen Release Level 
and delete data from it. 

Our embodiment also discloses one special type of 
Release Level known as a Sideways Release Level. These 
Levels always branch out from a regular Release Level, but 

35 unlike regular Release Levels, data is permitted to enter 
from a Private Library. This arrangement permits updates 
and "fixes" to problems found with data residing in a frozen 
Release Level. 
The PFVL structure lends itself to a powerful feature of 

40 the embodiment known as a Library Search Engine. In many 
commercial Data Management Systems, the means for 
establishing quality Levels often require physical segrega- 
tion of data into a conamon repository. Usually this entails 
making copies of the data to multiple locations. Although 

45 our preferred embodiment will permit data to be copied as 
it migrates from one Level to the next, the default action is 
for the data to move to the higher Level. The Library Search 
Engine can be used to pick a starting location in the Library 
Structure and seek out a collection of coherent data objects, 

50 regardless of their current Library location or physical 
residence. The Search Engine and it's imderlying algorithms 
are discussed in the Search Manager section. 

Now, in considering our Control Repository illustrated by 
FIG. 17 and our Data Repository ilhisU-ated by FIG. 18 in 

55 implementing oiu* system, an embodiment of a database that 
is used includes IBM's multimedia DB/2, or the databases of 
Informix which allow image and audio fields instead of plain 
text. With this kind of database, represented by the databases 
in the drawings, in the Control Repository, one could have 

60 image or audio fields. So a user could do a library search for 
all red sweaters that match a photograph of some hot new 
fashion design, at or above the PI price level starting with 
the ''Parisieone" version. (Hint: this scenario could be an 
implementation of our DMS in a large mail order clothing 

65 outlet which caters to Web shoppers. 

One can use a text database such as DB/2 as the Control 
Repository, combined with the mutimedia DB/2, or other 
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multimedia supporting database as a data repository. This 
would allow storage of the actual data, audio and images 
into DB/2 where the various pattern matching engines could 
be used, yet still allow the data to be ""controlled" or 
managed using our techniques with the cheaper and simpler 
DB/2 (which really only needs simple textbased tables to 
work). 

By using a multimedia database (e.g. DB/2 version) as the 
control repository, one could perform "queries" using voice 
commands like: "Display the Fix Management Data for Part 
18F4475" or "Show me electrical checking results for all 
schematics at the Ql level". 

FIG. 19 illustrates an example Library Structure. To 
clarify the example, the overall structure is segregated by 
Library File Type with inverted tree HO denoting the ASIC 
structure, and inverted tree 120 denoting the Firmware 
structure. To begin with, both trees have Working Levels 
_WL1, VLl.and VL2 in common. These are known as. the 
Default Levels and these would exist for all LFTs in the 
Library. Turning our attention to the ASIC structure, it has 
additional unique Levels known as WL2, WL3, CDl, CD2 
and CD3. This type of arrangement could be used to 
accommodate high Level design being done at the Default 
Levels, synthesized parts being processed on the WL2-WL3 
branch, and custom design being done at the CDl, CD2 and 2s 
CDS Levels. Although our embodiment permits data to enter 
into any of these Levels, the Data Manager controls the 
Entry Levels. In this example ASIC data may enter CDl, 
CD2, WLl or WU. 

The highest Working Level is VL2, and above that is the 30 
current Release Level known as AR3. Above that are frozen 
Release Levels AR2 and ARl. ARl is the original release of 
the ASIC design, and AR3 will contain the most recent To 
the left of Release Level ARl is Sideways Release Level 
ARPl. Additionally, Release Level AR2 has Sideways 35 
Release Levels ARP2 and ARP3. As stated above, when data 
enters any of the Release Levels except AR3, it is "trapped" 
and can't move to another Level. However, it can be located 
with the Library Search Engine. 
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The entire structure of every library in the DMS is stored 
in tables within the Control Repository. These tables show 
information about each Level denoting attributes such as 
Entry Level, Promotable Level and the physical location of 
the repository. In order to improve performance and 
availability, our preferred embodiment permits this struc- 
tural information to exist in an external file for quick 
reference by users running applications in their Private 
Libraries. An example of a struchire file is shown in FIG. 20. 

The strucmie file in FIG. 20 is divided into 6 sections. 
Each section contains the following four tokens: 

The first token contains three pieces of information delim- 
ited by a / in our preferred embodiment. The / can be 
used to parse the first token as follows: 

1. The LFT where XXX denotes ALL LFTs in the 
Library. 

2. The Version where XX denotes ALL Versions in the 
. .. . Library. ^ . 

3. The Som"ce Level where 00 is a special keyword 
denoting any user's Private Library. 

The second token is the Target Level 
The third token is a Put/Promote flag which decodes as 
follows: 

NN Soiiroe Level not Puttable/No Promotion Path from 

Source to Target 
NY Source Level not Puttable/Promotion Path from 

Source to Target 
YN Source Level Puttable/No Promotion Path from 

Source to Target 
YY Source Level Puttable/Promotion Path from Source 

tol>irget 

The name of the physical repository of the Target Level. 
This can be multiple tokens depending on the computer 
platform. 

Making use of parts of an existing Cadence TDM system 
Now having discussed PFVL as part of an AFS version, 
we note that among existing systems. Cadence does not have 
such an AFS version, but (toes provide DM software which 
can run on a Sun Microsystems Workstation. We have 



Since there arc 7 entry points (CDl, CD2, WLl, WL2, 40 concluded that the current Cadence system is insufficient for 



ARPl, ARP2, and ARP3), there are 7 independent search 
paths. The user may initiate a search for data at any point in 
any of these 7 paths. A search initiated at a Working Level 
or regular Release Level will move towards the "tree trunk'' 
and up to the oldest Release Level (ARl). The search path 45 
for CD2 would be: 

CD2-*CD3-*VL1-»'VL2^AR3-*AR2^AR1 
(terminator) 

Searches beginning at a Sideways Release Level will 



our complex needs. However, Cadence has an eflFective 
underlying command line interface for the TDM function 
which drives all TDM functions. This command line inter- 
face can be modified so as to incorporate it into our 
methodology with an AFS environment. 

Basically, our Data Management System needs to employ 
what we call the PFVL Paradigm. 

Remember to optimize data storage we use a PFVL 
paradigm to idenli^ all data in the DMS by Package, File 



migrate towards the "tree trunk" then tum upward towards 50 Type, (Data Type), Version and Level. Packages are arbi- 



the oldest Release Level Asearch beginning at ARP3 wotdd 
look like: 

ARP3-»'ARP2-*AR2— ARl (terminator) 
l\iming our attention to inverted tree structure 120, this 
represents the Firmware tree. In addition to the Default 55 
Working Levels, this tree has Working Levels FDl (which 
is an Entry Level) and FD2. It also shows Release Levels 
FR2 and FRl (which is frozen). FRl has one Sideways 
Release Level laiown as FRPl. 

Further unique stmctures can exist for each LFT in the 60 
Library, or an LFT can use the Default Structure. In addition, 
any stmcture may be replicated to form multiple Versions. In 
this way a single Library is equipped to handle a multitude 
of data management tasks. The only restriction on the 
present embodiment is that any given Level in the tree may 65 
migrate to one and only one higher Level. For example, CD3 
may not point to both VLl and VL2. 



trary divisions of data whereby all the data has some 
common association. The PFVL acronym was derived from 
IBM internal jargon, but the same principles can be applied 
using Cadence parlance as; 

Library — Variance — Quality Level — View — Cell — 
Version if our PFVL structure and principles are adopted, as 
they should be. The PFVL structure and process provides 
that every piece of data in the Data Management System 
(DMS), regardless of origin or importance, is tracked by 
PFVL. In other words which our PFVL structure and prin- 
ciples are adopted in a Cadence system every piece of the 
design, whether it's a schematic, piece of VHDL, a layout, 
or documentadon which is associated to a 

Library — Variance — Quality Level — View — Cell — 
V^on has all of the data associated so that the system 
ensures every piece of data has the PE^VL (here 6 attributes) 
associated with it 
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Furthermore, our DM principles state that all data and alert the Integrator if any versions become obsolete. The 
control information is tracked in an architecturally central- BOM Tradcer can also be used to perform promotions of 
ized location consisting of a Data and Control Repository. cohesive units of data between levels. 
An "architecturally centralized location" does not require Automated Library Processing whereby tools, checks, 
that all the data must be kept in a single Unix directory, nor 5 and automated tasks can be launched either during move- 
that all the control information must reside in a single mcnt of data between levels or while data is stable within a 
metadata file. Nor does it imply the whole system must be level. Results would be associated to the exact data objects 
governed by a single database. What is says is that the user used in the process (via the PFVL architecture) and retained 
must perceive the system in a manner by which all data in the Control Repository. These results can serve as pro- 
appears to be tracked uniformly. So, an example might be lO motion criteria to ensure data is promoted only when it has 
that I have a design for an MPEG decoder. The physical achieved the desired level of quality. The Data Manager 
design is done in Cadence so the actual layout data physi- would be able to "program'* his library to run any available 
cally resides in a "Cadence style directory structure'*. library Processes either in a particular sequence or in 
However, we have FrameMaker documentation which parallel. 

explains and diagrams the physical design, but as Frame- 15 External Data Control whereby results obtained from 

Maker documentation is done outside of Cadence, it is not tools run outside of the DMS can be securely incorporated 

stored originally as Cadence data. Physically this is kept in into the DMS with the same data integrity as an Automated 

a completely -different Unix directory,- maybe completely -Library- Process initiated from within the DMS: 

isolated by system and location from any "Cadence data". A Locking mechanism which not only performs simple 
Using our system, however, wherever the documenation is 20 Check-Out, Check-in to assert ownership, but allows own- 
located, the DMS still tracks both data objects by eiship by PFVL. So, two different designers could check out 
Library — Variance — Quality Level — Mew — Cell — different versions of the MPEG decoder at different Quality 
Vsrsion which enables the tiser to do things like findA^iew all Levels. An example might be that the primary designer has 
the data associated with the MPEG even if multiple pieces the decoder checked out at the lowest library level, but the 
of data are in physically di^arate locations. The reason this 25 PD Integrator finds a minor electrical problem at the highest 
works is that the system ensures every piece of data has level which is causing a DRC check to fail. He simply has 
these 6 attributes associated with it. The control repository to insert a buffer so he goes ahead and checks out that level 
can also be distributed as long as each component follows of the design, makes the change and chedcs it bade in. He 
the structure and process of the architecture. For example, can continue with the DRC run while he informs the primary 
the Cadence data to most quickly integrate our structure and 30 designer of the required change for the lower levels. This 
process of our architecture into a Cadence system, one locking mechanism would also permit surrogate ownership 
would use a routine for tracking the data by TDM using of the same piece or design, such that two people would 
TDM's control files to act as the Control Repository for the work on the same piece together. The system automatically 
physical design of the MPEG decoder. Likewise, all Frame- ensures only one has it diecked out at a time, but allows the 
Maker documentation might be tracked by a Lotus Notes 35 other to "take ownership" if he needs to. Automatic notifi- 
Database so that it can be made available to both designers cation and complete history tracking reduce the risk of 
and external folks simultaneously. As long as the TDM miscommunication among the partners. In addition the 
Control Files and the Lotus Notes Database adhere to the locking mechanism would also support other types of locks 
PFVL architecture, the user is hidden from the inner work- such as Move and Overlay whereby coherent sets of data 
ings. All he knows is that he runs some front-end script or 40 could be temporarily frozen into a Quality Level to prevent 
GUI menu where he can ask to find all the MPEG decoder accidental movement or obsolescence whfle a lengthy model 
information under a given cell name at a particular Quality build is imderway. 

Level of a particular Variance in a certain Library. The DMS Problem Fix Management and Engineering Change 

looks through the various physical Control Repositories, Tracking would provide various utilities to ensure that fixes 

finds the layout and FrameMaker views, finds their exact 45 to problems arc contained within the proper EC. In addition 

Version numbers and locates them in the proper physical certain information about the fix would be tracked in the 

data repository. Control Repository to enable various types of escape 

Our PFVL structure and process architectiu-e should be analysis, status reporting, etc. Mechanisms would exist to 

used in combinatioS, with many other useful Data Manage- prevent or minimize the risk of the same piece of design 

ment features which we have developed and explained. We 50 being associated with multiple ECs or a piece of design 

feel the following features should tie universally imple- being attached to the wrong EC. 

mented in combination with our PFVL structure: There are many other features of our preferred embodi- 

Using the PFVL architecture to set up a single logical ments which we could employ, but we need to implement 

Data Management system for design data (Cadence and these concepts and we have working algorithms which we 

non-Cadence), Various parts of the design are tracked in 55 have provided in these applications which are suitable for 

separate shared libraries. Each library would consist of N use with TDM and some of TDM's existing features, like 

Quality Levels and M Variances (N and M are determined by policies, can be employed as part of a foundation for our 

each Data Manager based on the type of information stored system. However all our algorithms expect the Control and 

in that library). Data Repositories to follow the PFVL architecture. Hence 

Adynamic Bill of Materials Tracker would exist to allow 60 implementation needs to ensure use of things like bierarchial 

PD, Hmtng and Simulation Coordinators (Integrators) to projects to properly emulate Quality Levels. We also need to 

easily identify all the desired pieces of a design at a ensure that Variances can be supported with the current 

particular Library, Level and \^ance to be built into a TDM architecture. In order to use the systems together, at 

"model**. Once integrated into the model, the BOM Tracker some point a conversion needs to provide the following 

would monitor the actual versions of the data objects and mapping: 
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Library • \%riaiice - Quality Level • View • CeUName > Veision (C&dence) 
to /\ /\ /\ /\ /\ /\ 
\/ V/ \/ \/ \/ \/ 

Package • Vbrsioa • Quality Level - l^pe - FQeyame • Iteralioa (IBM DMS) 



In other words we need to be able to use the TDM API to 
make queries about data using the above mapping, between 
PFVL attributes, regardless of name or origin, as the data 
may originate in IBM DMS, Cadence, ^ewLogic (see 
below) or elsewhere. 

Both private and public libraries need to be provided. 
With respect to private libraries Cadence employs Working 
Areas (a limited kind of Private library) in which a user can 
define one or more private libraries, each of which can reside 
in any physical AFS location desired by the user. All 
authorities are..are. done. through AFS, so the user controls 
who can access or update their private areas. There is a GUI 
which makes it easy for a user to set up a Working Area and 
create private libraries. TDM includes a special Integration 
Area (a limited kind of Public Library) which is designed 
specifically for people performing coordination or verifica- 
tion tasks. These areas are similar to the regular working 
areas in terms of how they are defined, but these have 
additional functionality which is further discussed with 
regard to our Library Manager. Private libraries are a func- 
tion of our own library management system. Wth regard to 
public libraries, Cadence's TDM uses a Project Manage- 
ment tool to assist the Data Manager in various DM tasks 
such as defining and maintaining public libraries. Hie DM 
may set up an unlimited number of Release Areas, but the 
system is limited and only permits one Integration Area per 
public Hbrary. Furthermore, the DM also has no control over 
the initial physical location of the data (in the Integration 
Area or Release Areas), and tbe system automatically 
imposes a single directory tree structure for tbe public 
library. We note that within AIX is a function called 
''permissions", and when TDM could be run in an AIX 
environment, when data must be relocated to another physi- 
cal repository, there is a TDM command to perform the 
function. In such an environment, since all authorizations 
would be done via an AIX permission, the DM would have 
complete control over file access, write authority, and data 
removal. 

There are several significant problems with this TDM 
system area of public and private libraries. The current TDM 
system fails to differentiate between a Working Area, an 
Engineering Area, a Level Area and a Release Area. In 
complex development projects, these are different and each 
of these area must be differentiated by any concurrent 
engineering staff. TDM makes it impossible for the DM to 
define any type of library structure with multiples levels 
and/or versions. One could try to change the use of a Release 
Area to mimic an engineering level, but the required amount 
of daily iteration combined with tbe required degree of 
parallelism makes this impractical in a commercial environ- 
ment. Integration Areas may be considered as having 
adequate characteristics to serve as a model for engineering 
levels, and data can be continually promoted into the Inte- 
gration Area until such time that tbe Integrator feels it should 
be released. However, TDM is restricted to a single Inte- 
gration Area per public library. This may be compared to our 
own public library methodology which permits multiple 
Integration Areas per public library. Without this function, 
along with others which we may note, which needs to be 
implemented in the system as we have described it, TDM 
would not satisfy necessary requirements of a complex 
system. 



A complex system requires the ability to define data types 
and perform aongraphical DM tasks. We note TDM offers a 
powerful selection of data management commands which 
enable a Data Manager to do virtually an entire job from 
outside of the Cadence TDM system. IBM's command line 
API interface allows, for instance, any existing BOM appli- 
cation to nm entirely in a system command line environ- 

15 ment. This allows for integration with nongraphical tools of 
third parties. This also provides the basis for data managers 
to write unlimited utilities (via C programs, shell s<7ipts, 
perl scripts, etc.) to automate orenhance- their productivity: 
But we note that Data Types must be selected firom a list of 

20 master cell views administered on a project wide basis. It is 
not evident that users can create a unique new Data Type 
themselves, even though they can create new data and select 
from existing Data lypes (cell views). Apparently, also, 
non-Cadence data can't be tracked by an existing Library 

25 Browser. Library processing, particularly private library task 
launching is an aspect of our own development In this 
regard. Cadence offers the concept of Policies to permit task 
launching against any data object in the DMS. With proper 
arguments, we believe that any executable code could be run 

30 from a policy. This would permit a user to call a system 
ftmction, third party tool, shell script, perl script, C program, 
etc. from within a policy. For conversion of an existing piece 
of code to a policy, an appropriate API code woulid be 
required. 

35 TDM has commands which can be invoked from a 
command line, within a script, program, or policy. This 
flexibility in the policy architecture of the tools when 
coupled with the set of TDM data management commands, 
does present the opportunity to combine our own develop- 

40 ments with this a^ect of TDM. While TDM invokes a 
policy from a TDM session, it is possible to launch a policy 
from an AIX window. To incorporate our developments, 
there would need to be tight integration of policy laimching 
from a Library Browser like that we have in our library 

45 managemeat function discussed below (although we note 
that Cadence provides a library browser without our 
functionality). 

We note that policies can be chained together such that a 
policy sequence can be run. However, the sequence in TDM 

50 is not determined by the Data Manager or user, but rather by 
sorting the policies in alphabetical order by name, then using 
that as the order of execution. Policies can be configured to 
launch during other DM operations, such as Check Out or 
Check In, or they can lun stand-alone. 

55 Public library task launching is required. In this regard, 
TDM provides that all policy functions are available to a 
Working Area (b. Private Library) and also available to data 
in an Integration Area or Release Area (Public Library). The 
existence of a fully functional command line interface in 

60 TDM allows the Data Manager or Integrators to perform a 
variety of tasks» without invoking a separate Cadance tool 
call Frameworic. 

Cadence also has a separate tool product PCS which 
allows one to graphically diagram a process flow. The user 

65 simply clicks on die various process boxes, and the tool then 
executes underlying policies. This provides a nice graphical 
interface to assist designers who prefer working with GUIs. 



04/19/2004, EAST Version: 1.4.1 



5,9^ 

77 

Basic design tasks and library promotion is handled by 
our development's library management system and Library 
Browser. In this regard, TDM uses a Working Area 
-to-*Integration Area -to-*Release Area paradigm as their 
basic design control flow. By mapping between their model 
and our model of designer library -to-*working library 
levels -to~^releasc levels, there is a close correspondence. 
The Cadence submission facility corresponds to a promotion 
utility for moving data from a Working Area to the Integra- 
tion Area, and from the Integration Area to the Release Area. 
The TDM front end allows one to perform Check Out, 
Check In, Promotion, Switching work areas, and viewing 
Integration areas. However, the user interface for the Work- 
ing area is inadequate, and does not serve as a Library 
Browser replacement 

Hie latest 4.4 Version of TDM is not capable of checking 
data out of public libraries, checking in, promoting to 
-integration-and release- areas,-displaying aodbrowsing data 
in integration and release areas and easily switching between 
multiple working areas. In the Cadence framewoik, all 
designer functions need to be executed from the library 
browser, and the subset of data management coounands used 
on a daily basis should be supplied, as this is an absolute 
requirement for our complex design systems environment. 

The Cadence system does not, as does our development, 
supply multiple ''integration areas" and our complex design 
systems environment does require multiple working library 
levels. Apparently, standard opinion is that one could use a 
shared integration area in order to keep a complex part, e.g. 
an EnUnit in the same library. What has not been appreciated 
with an Element and System Sim sharing the same integra- 
tion area, is that there is invariably a phase shift in build 
frequency. This makes the assumption of this prior work 
impractical, for they should not and do not always co-exist. 
Thus there is a need for our multiple integration areas and 
these need to be properly addressed to successfully imple- 
ment a complex design control system. 

Furthermore, our library management system, as we 
discuss, provides for extracting data from a public library. In 
our methodology both the integratois/coordinators/model 
builders and the designers need simple access methods to 
data in release areas. 

The prior art has treated releases as a static configuration. 
Thus, the Cadence TDM concept of a Release is a complete 
set of pointers to each component of an entire design, 
something akin to a Bill of materials, a static configuration. 
Release Areas always contain pointers to every piece of 
design. This makes model builds in the single Integration 
Area very straight forward since the integrator need only 
point to a Release as a starting point, then incrementally add 
in designer's updates and fixes. To do this the integrator 
must use a separate tool suite, which is awkward. But, as we 
have discovered, the designer(s) needs to access released 
data. The absence of such function would be catastrophic in 
a complex system design environment. \^th the current 
Cadence product, the designer is forced to use the TDM 
front-end to perfonn basic data management functions such 
as switching/viewing wodc areas, checking data in, checking 
data out, promoting data, and accessing integration and 
release areas (public libraries). In &ct, in the Cadence 
system, it is easy for a user to accidentally point to and edit 
a design's control data, instead of the design itself. The risk 
of designer error thus is imacceptable. 

Hiis is solved by our development by providing a way to 
sort data by cell name, or cell view, with a tree structure 
display, categories, etc. A user has, and should have, no 
access to control and meta data. Use of a prior art system 
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which oould require a designer to ping-pong between an 
unsatisfactory library browser and a rudimentary front-end 
is risky and unacceptable. 
Nevertheless, in fairness, we would say that we could run 

5 typical design DM tasks non-graphicaUy with the set of 
TDM commands coupled with a command line interface to 
permit any of the basic design functions (Check out, check 
in, promote, view work areas, view release areas) with the 
capabilities of an operating system like AIX. From an AIX 

10 command line, using script, or any type of executable 
program, this part of DM can be performed in such an 
environment. 

Our system provides a way for sharing/transferring data 
ownership. In ttus system, file locking mechanisms are 

IS present. Cadence's TDM offers two methods for locking 
files during checkouts. The first is an exclusive lock (the 
default) where check out of any version of a design com- 
ponent renders all other versions of-the -same component 
unavailable for editing. There is a problem with this 

20 solution, in that it not only prevents a second designer from 
updating someone's components, it also prevents the origi- 
nal owner from working on two versions of the component 
simultaneously. For example, if a bug is found in the 
Element and System sim models, and they contain two 

25 different versions of a component, the designer must check 
out, fix, and check in each version sequentially. 

Cadence also has a method using non-exclusive locks, 
whereby two different users may check out different ver- 
sions of a design simultaneously. Again there is a problem 

30 with this solution. Since the system won't allow the same 
user to hold two non-exclusive locks on the same piece of 
data, in the aforementioned example of an Element and 
System sim design bug, sequential fixes are still required 
(unless the original designer gets a second user to fix one 

35 version of the design while he fixed the other, sometimes a 
problem when the original designer is in the USA and the 
second designer is in Japan or Germany, France, England, 
Canada or one or more of many other countries, to indicate 
a real possibility). Furthermore, there is a possibility that a 

40 second user can grab and modify a different version of the 
design without the original owner ever knowing about it. 
The result is a system which has no utility for transferring 
ownership, as we have provided, making it difficult to 
operate on different versions of the design in parallel as 

45 required fi3r concurrent engineering. Furthermore, depend- 
ing on the type of locking employed, with TDM it may not 
be possible for another designer to act as a surrogate for the 
original designer in an emergency situation (i.e. Where the 
original designer has the file checked out and has to unex- 

50 pectedly take a leave of absence). The TDM system does not 
permit the DM to override or reset a designer's check out 
locks. 

Our system, we will note here, has a locking mechanism 
which enables transfer of ownership permanently or 

55 temporarily, and allows for an override or rest of the check 
out locks^ and provides notification to the original designer 
or administrator in the event of check out 

A system requirement in this kind of system is a Bill of 
Materials (BOM) mechanism which should have a satisfac- 

60 tory way to create BOMs, as we have provided. The 
Cadence Checkpoint Manger provides a nice mechanism to 
create Checkpoints (BQMs). Checlq)oints are manageable 
data d>jects, which means that they can be diecked in, 
checked out, promoted and tasks can be run against their 

65 members^ the Cadence system permits Checkpoints to con- 
tain other Checkpoints as members, thus allowing hierar- 
chical creation. All Checkpoint information is stored in an 
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ASC file, which, coupled by the TDM command line API Cadence policies can be used to achieve our problem fix 

interface, pennits the TDM to interact with third party tools. management functions. The mechanisms which we use to 

Our preferred embodiment, it will be noted permits lock- implement the tasks should be used, 

ing a Bill of Materials. In this regard, we note the TDM Our release manager enables making design changes for 

makes it possible to save all versions of a design component 5 subsequent releases. The TDM model of moving Integration 

and use pointers to denote which version is associated to the -to— Release area supports initial releases and sequential 

Integration Area or a Release Area. However, it appears wcU. Subsequent releases arc constructed using any 

possible to delete a version, and no mechamsm exists for the ^^^^ ^j^^ as a base and the sole Integrator has complete 

Coordmator to "lock down the versions of his model to ^^^^^^ ^^^^ Integration -to-Release Area path. The 

prevent this. No mechamsm appear to exm to prev^ ^^^^ ^ ^^g^^ ^^^^^ 

newer versions fitom cntermg the Level at which the Coor- i.cj r 1^ 

dinator is working, therefore he can't always be assured of ^^^^^^ ""^^^ has complete freedom of nomenclamre. 

working with the most recent data. However, with knowl- , ^f^'^'^ ^ TDM lacks any mheient concept of muluple 

edge of the way we provide for locking a Bill of Materials, ^^^^^^ structures withm a given project Although Integration 

one could modify the Cadence TDM paradigm to accom- serve as a single level, it does not permit the 

modate lock down. A coordinator would first build some establishment of sepcratc engineering and release levels 

type of model, and create a Checkpoint to track the contents wi'h the ability to physically segregate the data accordingly, 

of the mode,. After the model is working properly, it could Also, in this connection, we note that the Data Manager 
- on a later 'day be'declareda-success.-^I^inng-tbe' time'the' - can -t define any physical location of released data; and-TDM 

Coordinator first ensures none of the member, of the model automatically assigns new Release Areas to a directory 

disappear (are deleted or overlayed) and ensures that they 20 hanging off of a top-level directory for the entire Library, 

can't be accidentally promoted to another level. Secondly, Data can be displaced by a relocate function. Everything for 

the Coordinator would be enabled to know if, on the later project management is sequential. With the Cadence system, 

day, if any of the members of the model have become multqjle versions cannot satisfy the parallel developments 

back-leveh This may be achieved by a Cadence "policy" required for concurrent engineering, 

solution, where a policy code is written to set a '^freeze" flag 25 As we would note, our release manager allows the cie- 

against each member of a checkpoint. This would be satis- ^^j^ multiple "Integration Areas" making it possible to 

factory. . ^ , . ^ , . nm multiple ECs or Design versions in paraUel. Wc can 

One of the features present in Cadence s Checkpoint ^^g^^ ^^e physical location of released data. TTiis is impor- 

Manager is that the BOM can be static (which means the ^ j ^^j^^ ^^^^ components which require 

contents are a snapshot version numbers) or dynamic (which extensive ECs 

means the contents change to always include the most recent , / , , 

version of a component) Adding or deleting members of an , With our release manager, ECing a released component is 

existing BOM is relatively easy. We also update members of This task resolves around a designer accessmg a 

a BOM in accordance with our preferred embodiment. released piece of design, modifying it, and then releasmg it 

It wiU be noted that we have addressed the issue of under a new EC Wth TDM a designer via the user interface 

gathering BOM status or real-time BOM invalidation, some- ^5 can open a Release Area and check out a piece of data into 

thing not possible with such tools as provided by Cadence. any Working Area. This aUows a designer some flexibility in 

Furthermore, we can use the BOM as a handle to promote setting up multiple Working Areas or private libraries for 

the updates into an Integration or Release area from the different ECs. However, the users arc subjected to the 

Working Area. In addition, we provide "real-time" notifica- failings of the TDM user interface. Most frequent DM 

tion if members are deleted or modified. This capitalized 00 40 problems occur when a designer mistakenly sends a com- 

the ease in updating and deleting members in the BOM. ponent into the wrong EC stream. While with TDM, where 

It will be noted that we provide utilities for examining only one EC is processed at a time, one could minimize this 

BOM operations. In the Cadence system, the owner can problem by having a single Integration area for a Public 

delete the Checkpoint without affecting the data objects, but Library, but this requires the Integrator to ensure that he 

there is no convenient method for viewing the status of a 45 selects the appropriate target Release Area and handle the 

BOM or its members. Integration Area 4o-»Release Area promotion himself. Mix- 

We have provided a convenient set of utilities for use an ing components into the wrong EC stream is possible and 

examining BOM operations. We provide a method for risky. 

viewing the status of a BOM or its members. With our With regard to ECing a released component, mtiltiple 

provisions, in a TDM system, not only could an owner delete so Integration Areas could be provided and coupled to manage 

the Checkpoint without affecting the data object, but task data from multiple ECs. It is possible to iterate and verify 

laundiing could be built in for BOM members. To launch parts with Multiple Integration areas. However, one still has 

tasks in a cadence system, a Policy could be written to loop to properly implement the DMS to avoid having a part from 

though the members of the BOM and either laimch tasks different ECs mixing together, so our Design Control Sys- 

against them or determine their current version is most 55 tem if building models needs to be implemented, 

recent. Our method for BOM movement through a library is In our Design Control System we allow building models 

a substantial advance. Cadence's TDM has no BOM pro- from released data, This tasks requires Int^ators to be able 

motion mechanism. to easily access all components relating to a Release, and 

We have described bow we provide for BOM movement perform tasks such as netlisting a release. TDM has a single 

through a Library. Our ideas could be implemented in a 60 Integration area, and the Release is a pointer to a complete 

Cadence like system, when our ideas for multiple integration set of design components^ but there is no library browser 

levels are incorporated, by using the underlying Cadence support since some model build task may require launching 

Checkpoint mechanism to move BOMs through the Library tools from within the framework. TDM has no support for 

levels. multiple Integration areas, making it impossible to perform 

We have provided for program fix management, another 6S muhiple model builds in parallel. We discuss how to fix 

substantial advance. TDM has do built-in fix management design problems in multiple releases within our system. It is 

function. not possible with TDM to make simultaneous fixes. A user 
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is unable to Check out multiple versions of the same piece 
of design, even though the Release area structure does 
permit a Data Manager to establish area for "patches" to 
Released data (i.e. design patches for the test floor. 

>^th the Design Control System it is possible to conduct 5 
an ISO approved verification audit. Cadence has no way of 
conducting an ISO approved verification audit as a task* so 
adoption of our our process management function and our 
release manager methods needs to be employed. 

An ISO approved verification audit requires a ISO Quality 
Record. This task requires a DMS capable of storing results 
from tasks along with the proper pedigree information for 
the files used to run the tasks. It can then be enhanced to 
produce output in a comparable format to the ISO Quality 
Record In this connection we use our process management 
function and our release manager. 

Making use of parts of an existing ViewLogic system 

As jve wiUjdiscuss^ various changes which jieed . to be_ 
adopted for existing software in order to make use of part of 
that software in our new environment, we note that \^ew- ^ 
Logic provides software tools for Unix type workstations, 
such as the preferred AIX version which is enable of 
running in an AFS environment Again, we believe that the 
current ViewLogic software, which is now insuflScient for 
our complex needs. Deeds to be changed. ^5 

ViewLogic's View Data is based on ASC files which can 
be edited and viewed and easily maintained. Nevertheless, 
our PE^VL structure and principles need to be adopted, 
whether a^ects are called 

Package — ^fe^s^on — Quahty Level — Type — FileName — 3Q 
Iteration (IBM DMS) or 

Library — Variance — Quality Level — View — Cell — 
Version 

or some other name, version, level, type, filename, iteration 
structure if our PFVL structure and principles are adopted, 35 
as they should be. The PFVL structure and process provides 
that every piece of data in the Data Management System 
(DMS), regardless of origm or importance, is tracked by 
PE^VL. In other words which our PFVL structure and prin- 
cq>les are adopted in a Cadence system every piece of the 40 
design, whether it*s a schematic, piece of VHDL, a layout, 
or documentation which is associated to a 

Package — ^\fersion — Quality Level — Type — FileName — 
Iteration (IBM DMS) or 

Library — Variance — Quality Level — View — Cell — 45 
Version 

or some other name, version, level, type, filename, iteration 
structure has all of the data associated so that the system 
ensures every piece of data has these 6 attnbutes associated 
with it. 50 

Here we would recommend ViewLogic adopt our DMS 
including 

(a) our DM principles slate that all data and control 
information is tracked in an architecturally centralized loca- 
tion consisting of a Data and Control Repository; 55 

(b) using the PFVL architecture to set up a single logical 
Data Management system for design data (>^ewLogic and 
non- ViewLogic); 

(c) providing a dynamic Bill of Materials Tracker to allow 
PD, Timing and Simulation Coordinators (Integrators) to 60 
easily identify all the desired pieces of a design at a 
particular Library, Level and Wiance to be built into a 
"moder, eta; 

(d) provkiing Automated Library Processing whereby 
tools, diecks, automated tasks can be launched either during 65 
movement of data between levels or while data is stable 
within a level and where results would be associated to the 
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exact data objects used in the process (via the PFVL 
architecture) and retained in the Cbntrol Repository; 

(e) providing External Data Control whereby results 
obtained from tools run outside of the DMS can be securely 
incorporated into the DMS with the same data integrity as an 
Automated Library Process initiated from within the DMS; 

(f) providing a Locking mechanism which not only per- 
forms simple Check-Out, Check-in to assert owneiship, but 
allows ownership by PFVL, so, two different designers 
could check out different versions of the piece of a design 
element at different QuaHty Levels; and 

(g) providing Problem Fix Management and Engineering 
Change Tracking which would provide various utilities to 
ensure that fixes to problems are contained within the proper 
EC. 

Now, when one reviews the ViewLogic product, we can 
with our own perspective, interpret the N^ewLogic Working 
Areas as-able to serve as a limited-kind of Private Libraries:* 
Users must first be assigned to the ^Team" by the Data 
Manager. Once they exist on a Team, they may create as 
many Working Areas as they desire, and they can locate 
them anywhere in the directory structure of an AFS system. 
ADC permissions serve as the only means of authorization, 
so the user has complete control over who has access to their 
data. The Working Area is always driven by the existence or 
absence of the physical files. This means data can always be 
created or deleted from outside of VlewLogjc's ^ewData, 
and the Working area is guaranteed to provide an accurate 
image. 

Unfortunately, while it is easy for a user to create multiple 
Working Areas, the ViewData DMS has an awkward user 
interface for managing multiple areas. For example, the user 
can't display all the files in multiple areas at the same time. 
They must switch between Woddng Areas via a Set Envi- 
ronment frmction, which does not provide adequate visual 
cues to assist the user in knowing where they are currently 
pointing to. This makes it difficult to use and adjust to. 

The ViewLogic's ViewData uses a Team paragigm to 
perform shared data management. This is somewhat analo- 
gous to a Public Library. Each Team may have any nimiber 
of Release Areas, and members of a Team. Each member 
may have unlimited Working Areas. The DM can create 
Release Areas, specify the physical location of the data, and 
rename or delete the Release Area at any time. While 
A^ewData can be flexible in creating Release Areas, the 
architecture does not differentiate between levels. A DM 
can't define the type of structure required for concurrent 
engineering with multiple levels. Promoting data between 
Release Areas is not adequately addressed. Furthermore, the 
architecture requires the user to only permit the user to look 
at data in one Working Area and one Release Area at a time. 
There is no way to look at data in all Release Areas 
simultaneously. All data is stored in a Vault during a Check- 
In operation. Since data can be checked in while residing in 
a Working Area, or during a desired promote to a Release 
Area, the Library Mew imposes the restriction that a user 
must use the Set Environment function to point to a Working 
Area and one Release Area. The view refreshes to show a 
union of all the data in those two repositories. If the user then 
wants to see data in a different Release Are, they must again 
use the Set Environment. Since there is no way for the user 
to look at all Release Areas simultaneously, even the sim- 
plest DM maintenance and debug tasks (which are easy in 
our system) in ViewData are a virtual nightmare. 
Furthermore, the concept of unionizing data between a 
Working Area and a single Release Area causes problems 
which is solved by our system. 



04/19/2004, EAST Version: 1.4.1 



5,9t 

83 

ViewData could be modified through the use of an RCS 
version Segregation to create "virtual** levels and Versions 
according to our teaching. This would be very similar to how 
we use static configurations today as virtual Levels. 

VicwLxjgic's Data Management functions can be per- 
formed from within their GUI or by updating ASC files 
which hold all the Library Configuration information. The 
ViewData DMS allows one to work with data imported from 
outside the ViewLogic environment. We have copied a 
Cadence symbol from one of our designs into a ViewLogic 
subdirectory serving as a Working Area. By simply refresh- 
ing the Library View, our Cadence symbol appeared as a 
new data object with a visual cue indicating it is in an 
unmanagpd state. Thus we have shown that the existing 
ViewData tools allow the end users to have the power to 
define new data types by simply creating them or copying 
them into their Working Areas. This can be done via the GUI 
-and by selecting the Data Type-from a- list *of Data Types 
defined by the Data Manager for the Team. 

V^th regard to om private h1>rary task launching part of 
our preferred embodiment, we note that we could use 
ViewLogic scripting language known as ViewScript to pro- 
vide for any command line activity to be launched from the 
Libaiy A^ewer. A built-in API permits tasks to be chained 
together, and \^ewScripts can be written to test the results of 
one task before proceeding with the next task. All task 
launching is controlled by a single ASC file which may 
reside in a centralized location for a project, or each user 
may have their own. ^thin this file, the user may use the 
API to launch a task such as MTI Compile a stand-alone 
view script which may be simple or compiles, and imbed 
actual MewScript code to do more complex things such as 
chaining tasks together with dependency. Once the file is 
saved, the new task appears in a task menu within the 
Library Viewer. It is simple enough that users of ordinary 
programming skill can launch bottom line commands in 
accordance with our modification. 

With regard to our public library task launching we would 
note that all the task functions available to a private library 
should also be available to a public library. However, our 
experience is that ViewLogic does not provide any such 
function, although, theoretically they must know how to 
enable this function. However, ViewLogic has no distinct 
command line interface, and therefore the graphical View- 
Data product must be invoked momentarily even if the intent 
of the user is to launch a task which can be run non- 
graphically, such as a CLSI compile. 

With regard to our E)esign Control System's basic design 
tasks and hbrary promotion ViewLogic*s Mew Data is not 
suitable for concurrent engineering in which: designers only 
perform a Umited amount of verification before sending data 
to a public or shared library; 

designers frequently need to wodc with badc-level data; 

people performing verification frequently require shared 
access to all parts of a design; 

designers may have to work on multiple versions of the 
design in parallel; 

designers may "own" many design components; 

designers may share pieces of the same design (i.l. A 
logic designer writes VHDL, and a circuit designer 
creates layout), and 

designers may belong to multiple "Teams". Within Vkw- 
Data's design environment a user tends to work on an 
isolated piece of design, belonging to a single Team. In 
this paradigm the user tends to reside in the same Work 
Area and iterates within their private hbrary until the 
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design is stable enough to be ''released" into the public 
library. This paradigm assumes an orderly sequential 
design flow where the user is only interested in working 
within the latest version of design, and rarely needs to 
5 access back-level data. The designer is assumed able to 
perform all the necessary task with little need for data 
sharing. Within this limited structure, the ViewData 
system provides the necessary tools to edit, update, 
verify and release the design. 
10 However, when faced with a concurrent engineering 
approach, many of the needed characteristics simply don't 
exist in the ViewData product. For example, once a designer 
performs a Set Environment to point to the proper Working 
Area, its possible to browse and edit any data residing in that 
IS Working Area; however, if a designer needs to work with 
data in a different Working Area, he must switch the envi- 
ronment. This makes it impossible to see all of a designer's 
• data-simultaneously. - -• ............ 

The ViewData system requires the designer to Check Out 
20 a piece of data in order to edit it. This is the correct 
implementation, however, the system further employs the 
restriction that data must be checked out (owned) by the 
designer to simply browse the data. This is true whether the 
design is an isolated text file (like VHDL), or has hierar- 
25 chical dqiendencies (schematics). Basically the usisr must 
check out all components of a schematic in order to properly 
browse the schematic. This makes it difficult and impossible 
to share pieces of design or employ scenarios where multiple 
people anywhere need to debug a problem. 
30 ViewData's library browser uses a pair of icons to rep- 
resent the state of a data object The icons clearly indicate 
whether the current version of an objea is managed or 
unmanaged, and whether it's up to date or obsolete. The 
system has built in safeguards to prevent a back level piece 
35 of data from accidentally being promoted. However, in our 
concurrent engineering approach, we solve the need to 
promote back-level data at required times, so the lack of this 
capability in 'WewData's design is a detriment of this prior 
attempt. 

40 V^ewLogic's Work Area approach imposes constraints on 
design which are unacceptable from a concurrent engineer- 
ing point of view. Data is automatically sorted by class (Data 
TYPE) as opposed to design component names. There is no 
way to re-sort the data. As a preferred concurrent engineer- 

45 ing approach useable under our design control system can 
and ^ould be based on working with all types of a given 
component, use of a MewLogjc system to implement this 
approach would become cumbersome for designers owning 
many pieces. The visual clues provided by the ViewLogic 

50 system for indicating which Work Area a user is currently 
pointing to are insuflBcient. If a user has multiple Work 
Areas, it's loo easy to begin working in the wrong area and 
not realize it. Furthermore, the Set Environment can switch 
back to a default setting without the user knowing a switch 

55 occurred. This creates numerous problems if the user is in 
the midst of editing a check out piece of data, and then 
checks it into a wrong Work Area by accident. An when the 
designer is unaware, a concurrent user cannot be aware, and 
so could later chedc out the piece of data placed in a wrong 

60 Work Area by accident, and further compound the problem. 
Our concept of promoting data from a Private to a Public 
Ubary in the ^^ewLogic environment has similar problems. 
For example, the user must be pointing to a proper Work 
Area/Release Area union (using the Set Environment 

65 function) BEFORE initiating a "promote". The ad of pro- 
moting a file in ViewData is called a Check In and Release, 
which consists of simply cliddng on a menu pick. Since 
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ihere is no user interaction, failure to set the proper Work We provide for sharing/transferring of data owrteisbip. 

Area/Release Are union results in a promote where data is Within the V^ewLogic system the only means for formal 

either taken from the wrong source, deposited in the wrong transfer of ownership is the act of one user checking a file 

repository, or both. The user may never know this occurred. i°» followed by a second user checking it out. This system 

There is no means to perform an automated hierarchical 5 thus is not adequate for concurrent engineering because it 

promote where the user points to a top level schematic, and relies on personal communication and coordination, 

the DM system automatically traverses the design to gather Furthermore, suppose, as happens, two users have different 

all the iiBtantiated components. versions of the same design component checked out for edit 

Another major issue making ViewData an unacceptable simultaneously. Because one was not aware of die other, 

substitute to our Design Control System is the absence of a lO ^mil il comes time for one user to j^mote his modification 

method for promoting data between Library Levels (Release ^ Public Library, a problem will arise. However, even 

Areas). The ViewLogic DM system does not support this when the user has promoted his modification into a Public 

concept in a suitable manner for integrated design control. In Library, that user does know that someone has another 

N^ewData, promotion of all data fixjm Level A to Level B version check out, but is unable to find out which other 

requires a user to check out all the data into a Working Area, 15 version and who has it locked out This is not a trivial 

switch environment to a new Level, and perform the Check problem, because in a concurrent engineering environment 

In and Release function. In addition to being cumbeisome different users constantly need to update the same piece of 

-this is not-possible under certain situationsr Since check out - desiga at diffemt levels without. any. knowledge of another's 

implies acquiring ownership, this means the Data Manager actions. The result is a loss of data integrity, 

must be able to get ownership of all the data at Level A. If 20 We provide a built-in utility to transfer ownership, notify 

a designer in a concunent engineering enviionment is in the another requests ownership, and provide a 

middle of an update, this is not possible with ViewData. facility to monitor who has various versions of a design 

MewLogic needs to have the ability to sort the Library checked out at any point of time. Our solution provides a 

\^ewer by design component, something now absent in the foreman mechanism allowing multiple versions of a data 

ViewLogic system, yet one which we have provided. 25 object to be updated simultaneously, with multiple owner- 

Wc provide for extracting data from a Public Library; ships and notification being handled as appropriate for the 
however, the MewLogic DMS has no adequate substitute 

function. In the best case, with ViewLogic. the user must We note that running ViewLogic DM functions or tasks 

perform a Set Environment function and establish a proper can be performed oongraphically in a way accommodating 

Work Area/Release Area union before any data can be 30 our own design control system, making changes to follow 

extracted from a Public Library. Thus a user needs to have preferred embodiments possible, 

knowledge of which Wbik Area was used as a source of Regarding a comparison of the yiewLogic system, with 

promotion into the Release Area, something not assumable manner we employ for creating a bill of materials, 

in an integrated concurrent engineering environment. As a MewLogic DMS offers the concept of a Collection and a 

single data object promotes though multiple Release Areas, 35 Checkpoint. The difference is that a Checkpoint is a static 

it gets more difficult to undcistand the association. The snapshot of a coherent aggregate of data d>jects identified 

Ubrary View can display all existing versions of an object, by their exact version numbers, analogous to our BiU of 

but nothing in the system indicates which version is cur- Materials. A ViewLogic Collection is a grouping of data 

rently residing in which Release Area. Furthermore, the only objects where each oject in the gfoup is always the latest 

type of sorting is by Data Type, so all levels of a schematic 40 version. The purpose of a Cbllcction is to act as a "handle" 

are mixed together. In short, the only means a user has of which the iiscr can perform tasks on the entire group with 

extracting data from a Level, is to perform the Set » single invocation. This concept is similar to our File 

Environment, Qick on Check Out and hope for the best. In Groups. 

many instances, this may work properly, but when data The ViewLogic primary utility for creating and modifying 

exists in multiple Levels, this means possible severe data 45 either type of aggregate is the Collection Editor. This tool is 

integrity risks. ^d enables one to easily create Collections and 

Our integrated design control system for concurrent engi- Checkpoints as well as add and delete members. This 

necring allows a user to work with back level data (e.g. for includes aeating hierarchical Collections and Checkpoints, 

fast-pathing sim fixes). When one understands this and can Despite this advanced function in the ViewLogic system, it 

compare it with the ViewLogic system, it will be appreciated 50 Poses problems in trying to achieve BOM tracking in an 

that that system has major limitations. For example, if a environment like oiirs. The ViewLogic system requires the 

Version 1.5 is checked into a Level 1, and a Version 1.6 is ^ser to check out or "own" all members they wish to include 

checked into Level 2, any attempt to then work with Version ^ the Collection or Checlqjoint. Consider the ease where an 

1.5 results in difficulty. The system default is to encourage Element Simulator wants to build a BOM containing all 

a user to work with 1.6 because it assumes the user is 55 members in a sim model. The CheckpoiQt would appear, 

mistakenly grabbing an obsolete version. ^pon a first impression, to be a solution, however, the 

Any improvement of the ViewLogic system in connection Element Simulator must first check out all the versions of 

with extracting data from a Public Library would need to ^^^^ ^ model. This immediately leads to: 

addresss permanent storage. ViewData has no method to (1) the need for the Element Simulator to have enough 

delete unwanted versions from permanent storage. Thus, in 60 AFS space in his Working Area to hold the snapshot of 

the event a user makes a mistake and promotes data to a data, something not easily addressed; and 

wrong Level, there is virtually no way to clean it up (2) the problem of data integrity previously mentioned 

properly. Also, as the project matures, and numerous ver- because of the lack of any way for multiple versions to 

stons materialize, the Data Managers request some way to be updated simultaneously, as the designer is most 

delete the old unwanted data to reclaim space and clean up 65 likely needing to work with back-level versions of data, 

libraries. This is a problem with ViewData that needs to be Given this severe Liinitation, the possible power of Col- 

addresscd to adopt our preferred process. lections and Checlq>oints, is inadequate for a concurrent 
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engineering approach like that of our integrated design 
control systeai. 

The Viewlogic BOM handling needs to have an ability to 
e}q}and a Checkpoint in a Library Viewer and utilize the 
icons as a visual cue to represent the BOM status. These 
would be modifications that could be employed withio 
VIEWLOGIC to make this area satisfactory. 

We provide the ability to examine BOM operations/ 
utilities. V^ewLogic, in this regard, allows management of 
Collections and Checlq)oints data objects in their own right, 
as they are afforded the same treatment as regular data 
objects. For example, Collections and Checlq)oints each can 
be Checked Out, Checked in. Promoted (with some 
difficulty), and Deleted, and ViewScripts can be written to 
run tasks against their members. Thus functions can be 
performed against THE BOM without adversely affecting 
the data objects being tracked by the BOM. The iconized 
-^representation*of ' the -BOM- members in the Libraiy-View 
allows the user to obtain the cunent status. 

However, BOM movement through the library, like that 
we provide, is severely limited in the ^ewLogic system, so 
our methods should be adopted. We do acknowledge that it 
is possible to promote a Collectk)n, but with difficulty. After 
repeated tries, we have learned that if one accepts the 
restriction that a user must ''own" all members of a 
Checkpoint, then one is able to promote an entire BOM finom 
a Private Library into a Public Library. However, since the 
problems we discussed with respect to Level-to-Level pro- 
motion of regular data objects, which also pertain to BOMS, 
exist, there is no ability to move large BOMs easily from a 
Private Libary into a Public Library. This is a real short- 
coming of the ViewLogic system and a compelling reason 
we believe of adopting our total system. 

While design tasks can be performed iK)n-graphically in 
the \^ewLogic system, it is not possible to perform BOM 
tasks non-graphically. While ViewScripts can be written to 
perform many functions involving Collections and 
Checkpoints, they require ViewLogic VicwData to be run- 
ning in a graphical environment There are a number of 
disadvantages to such a system, illustrating the need for our 
system's ability to perform BOM tasks nongraphically. For 
example, if a timing model can be created using a non- 
graphical timing tool, it should be able to interact with a 
BOM tracker non-graphically. We provide for a command 
line environment, and it is important for a BOM tracker, as 
we provide (see the Section 4.6 discussion), to coexist in the 
same environment as the tool it is intended to work with. 
This is not possible with the ViewLogic system. 

There is a need for the problem fix management as we 
provide. ViewLogic DM has no built in fix management 
functions. 

Some fix management functions with the ability of View- 
Logic to execute specially written ViewScripts could be 
achieved. There was a proposal to address these concerns. 

It must be easy in an integrated design control system to 
make design changes for subsequent releases. When one 
tries to track an equivalent of our functions onto the View- 
Logic system design difficulties arise and the effort becomes 
difficult, even though at the highest level it is possible to 
make design changes for subsequent releases. We have 
achieved this result with unnecessary difficultly because we 
determined that because there is no type of Working or 
Engineering Level and one is forced* to use the Release 
Levels for design iteration in the ViewLogic system. This 
requires one to perform Level-to-level promotions^ which 
have the problems previously mentioned. One then desig- 
nates a specific one of the Release Areas as a Release Level. 



1,201 

88 

In order to make a design change, that data must be 
referenced. To do this one could create an overall system 
level Library and create a schematic instantiating compo- 
nents firom the other Teams. Upon librarying that schematic, 

5 is is still difficuJt to work with the combined set of data. 
Because of the Working Area I Release Area Union para- 
digm forced by the system, a designer is unable to see all of 
the data, comprising the overall schematic, simultaneously. 
Instead, the designer must repeatedly use the Set Enviroo- 

10 ment function to cycle through the various Working Area/ 
Release Area combinations. Also, no data can be browsed in 
the public areas. All data has also to be checked out into the 
designer's Working Area, just to look at it. Finally, working 
with multiple Teams is cumbersome, even though the Data 

15 Manager has complete control over establishing the Release 
Areas, including their physical locations, and no Library 
Search mechanism is necessary, siixx the release area which 

•• • has been designated -as* a- Release- Eevel- consists-of a-com- 
plete set of pointers to the components used in the overall 

20 design. While making it possible to achieve the base result, 
this system is unnecessarily difficult and not coixiucive to 
concurrent engineering in an integrated design control sys- 
tem. 

One of the aspects of desirable concurrent engineering 

25 would be the ability of the system to EC a released 
component, particularly when there is the ability to release 
control if multiple ECs are being processed in parallel 
without risking that data can be intermixed between the ECs. 
The problem with the paradigm used by ViewLogic is that 

30 an EC stream is represented by a Working Area/Release 
Area Union. We have noted that there is a lack of visual cues 
indicating the current union, and a possible promotion 
mechanism with no user verification of the source and 
destination. There is also no means to delete a version if it 

35 enters the wrong storage vault, making it impossible overall 
to minimize the risk of components being released into the 
wrong stream, something that must be avoided. 

With regard to building models firom released data, akin 
to the method we discuss, the ViewLogic system provides 

40 that a Release Area contains a full set of pointer to the entire 
design; however, a model builder must check out all the data 
into his Working Area. This is inefficient use of AFS space, 
especially if multiple models are to be built in parallel, since 
to achieve this task the user must set up multiple Working 

45 Areas to use as model build areas. 

View Logic allows the Data Manager to establish neces- 
sary Release Areas to house "patches" to released data (i.e. 
design data patches for the test floor); however, the act of 
creating and releasing such patches often entails a designer 

50 working on multiple versions of a design component in 
parallel. The current ViewLogic system has many problems 
related to multq)le check outs of the same component and 
working with back-level data. We would refer by way of 
contrast to the sets we use in fixing design problems in 

55 multiple releases. 

ISO approved verification audits, which we discuss under 
Section 6.6, requires a DMS capable of storing results from 
tasks along with the proper pedigree information for the files 
used to run the tasks. It can then be enhanced to produce 

60 output in a comparable format to an ISO Quality Record. 
The current ViewLogic system offers no such mechanism, 
and our process management function and our release man- 
ager methods needs to be employed. While we have 
described our preferred embodiments of our inventions, it 

65 will be understood ±at those skilled in the art, both now and 
in the future, may make various improvements and enhance- 
ments which fall withio the scope of the claims which 
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follow. These claims should be coastrued to maintain the 
proper protection for the inventicHis first disclosed. 
What is claimed is: 

1. A method for computerized design automation 
comprising, 

accessing a file and database management system fiDr 
managing a plurality of projects as a design control 
system, 

organizing data repository for each project for data 
records and a control repository comprising a ooomion 
access interface and one or more databases, 

said control repository communicating with users of said 
design control system for fulfilling requests of a user 
and the data repositories of said data management 
control system through a plurality of managers, each 
manager performing a unique function; and 

combining selected ones of said managers for supporting 
an computerized design automation application envi- 
"*^**-ronment suitable"for'multiple"users of a-user commu- 
nity located at workstations anywhere in the world 
accessible via a network, an intranet, extranet or via the 
internet; and 

defining for each project a control repository and one or 
more data repositories to store, manage and manipulate 
any data object, whereby said control repository com- 
municates with users and the data repositories in 
numerous ways to support environments ranging fiom 
a small user community to a global enterprise; and 

tracking all data and control information in an architec- 
turally centralized location consisting of said data 
repository and said control repository using a single 
logical PE^VL paradigm to identify all data in the DMS 
by Package, File Type, (Data Type), Version and Level, 
and wherein packages are arbitrary divisions of data, 
whereby all the data has some common association to 
a library. 

2. A method for computerized design automation accord- 
ing to claim 1 wherein every piece of the design which is 
associated to a 
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Library — Variance — Quality Level — View — Cell — 
Version has all of the data associated so that the system 
ensures every piece of data has all its PFVL attributes 
associated with it, permitting every piece of data or 
attribute of a design element in the Data Management 
System (DMS), regardless of origin or importance, to 
be tracked by its PFVL single logical association of 
every piece of the design. 

3. A method for computerized design automation accord- 
ing to claim 1 further comprising, providing that data 
management model structure capable of tracking a plurality 
of data objects governed under similar or disparate 
processes, wherein all objects are classified as part of a 
library, having one or more types^ each type having one or 
more versions, and each version having one or more levels. 

4. A method for computerized desigp automation accord- 
ing to claim 3 wherein said library is a grouping of objects 
which all have common characteristics causing them to 
belong to the same library grouping, and wherein within a 
library, data is organized by version, wherein versions allow 
parallel evolution of the same component data element to 
coexist in the same library enabling multiple versiois of a 
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component data element to be developed in tandem while 
using the same object name and residing in the same library 
and at the same level simultaneously. 

5. A method for computerized design automation accord- 
^ ing to claim 4 wherein for each said version, there is a level 

stmcture denoting a degree of completeness, stability or 
quality control enabling said data manager a means to 
establish a level structure commensurate with the goals and 
10 objectives of the user community. 

6. A method for computerized design automation accord- 
ing to claim 5 wherein at least some of the data objects are 
at a level diained to another level to allow data to migrate 
from one Level to the next, and wherein any or all of these 
Levels can be designated as Entry Levels allowing data to be 
entered into this Entry Level from a user's Private Library; 
and wherein there are also leyds categomied asjwrk^^ 
levels and release levels wherein data in working levels is 

20 transitory, and must eventually migrate to a release level, 
while release levels provide permanent storage vaults for a 
coherent set of data. 

7. A method for computerized design automation accord- 
ing to claim 1 further comprising, providing an architectur- 

^ ally centralized location which does not require that the 
location be physically in the same location but requires that 
the user must perceive the system in a manner by which all 
data appears to be tracked uniformly which enables the user 
to do things like findl/view all the data associated with the 
design when multiple pieces of data are in physically 
disparate locations. 

8. A method for computerized design automation accord- 
ing to claim 1 further comprising, the steps of mapping in 

35 order to use the system together with other systems the 
system attribute for conversion to provide the following 
mapping: 



^^r^ance - Quality Level - View • CtUName - VBrsicm 
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\taioa - Quality Level - Typt - FUeName - Iteration. 



9. A method for computerized design automation accord- 
ing to claim 1 further comprising, providing that the system 
provides working areas which serve as a private library for 
a \iser assigned to a team by a data manager, and to peiform 
shared data management each team may have any number of 
Release or Integration Areas, while team members may have 
unlimited Working Areas and the system data manager can 
create release or integration areas, specify the physical 
location of the data, and rename or delete the Release or 
Integration Area at any time, and create virtual levels to 
define the type of structure required for concurrent engi- 
neering with multiple levels and variances, promote data 
between virtual levels and into Release Areas, and enable 
users to look at data in all Release or Integration Areas 
simultaneously. 

10. Ametbod for computerized design automation accord- 
ing to claim 1 further compri^ng, enabling with said PFVL 
single logical paradigm attributes of non-system originated 
data to be tradced and made accessible along with system 
originated data with a system command. 

11. A method for computerized design automation accord- 
ing to claim 1 further comprising, enabling a user call for a 
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system function, third party tool, shell script, perl script, C execution of Don>DMS tasks through the use of an Auto- 
program, or any other type of application programming reader virtual queue. 

interface from within a user system may be invoked from a 18. A method for computerized design automation accord- 
command line. iog claim 1 further comprising, enabling accessible mul- 

12. Amethod for computerized design automation accord- 5 tipl© working library leveU, and means for extracting data 
ing to claim 1 further comprising, enabling a locking mecha- ^ public library. 

nism which enables transfer of ownership permanently or 19. Amethod for computerized design automation accord- 
temporarily of PFVL data, and allows for an override or rest ^0 5 ail data objects are identified by name and 
of the check out locks, and provides notification to the A.i_jr ..jj. . , 

original designer or administrator in the event of check out. lo . 20.Aa«thodforcompMerizrf design au^^^^^ 

?i A ♦if J r . - J J • . -J mg to claim 19 wherein at least some of the identified data 

13. Amethod for computerized design automation accord- J .^^^^^ ^, ^ ^^^^ ^^^^ ^^^^ ^ ^ 

mg to claim 1 further comprising, providmg that all data and the objects as files 

control information is tracked in an architecturally central- 21. A method for computerized design automation accord- 
ized location consisting of a data and control repository for ^isdiD 19 wherein at least some of the identified data 

a project using a single logical PFVL paradigm, and wherein 15 objects are identified by a type of daU object which depicts 
said system provides a dynamic Bill of Materials Tracker to the objects as files, while other data objects identified by the 
identify all the desired pieces of a design at a particular same file name exist, such that an entity of said data 

Library, Level and Variance to -be built into -a "model" - management system characterized by a^single name may 

14. Amethod for computerized design automation accord- have multiple types of daU objects, simultaneously residing 
ing to claim 1 further comprising, providing that all data and 20 in multiple Levels, of multiple versions and spanning mul- 
control information is tracked in an architecturally central- tiple libraries. 

ized location consisting of a data and control repository for 22. Amethod for computerized design automation accord- 
a project using a single logical PFVL paradigm, and wherein ing to claim 6 \^erein at least some of the data objects when 
said system provides Automated Library Processing the data is promoted into a release level, that Level is frozen 

whereby tools, chedcs and automated tasks can be launched 2S and a new release level is opened such that data always 
either during movement of data between levels or while data migrates from the highest Working Level into the current, or 
is stable within a level and v/hcrt results would be associated open. Release Level. 

to the exact data objects used in the process and retained in 23. A method for computerized design automation accord- 
the Control Repository. ing to claim 6 wherein at least some of the data objects when 

15. Amethod for computerized design automation accord- 30 the data is promoted into a release level, that Level is frozen 
ing to claim 1 further comprising, providing that all data and and a new release level is opened such that any working 
control information is tracked in an architecturally central- level may be promoted to from another working level, or 
ized location consisting of a data and control repository for serve as an entry level for data coming from a Private 
a project using a single logical PFVL paradigm, and wherein Library while a current Release Level can be promoted to, 
said system provides Problem Fix Management and Engi- 35 but can't be an entry point for outside data and frozen 
necring Change Traddng which would provide various Release Levels are neither entry points nor are they promot- 
utilities to ensure that fixes to problems arc contained within able. 

the proper release or EC. 24. A method for computerized design automation accord- 

16. Amethod for computerized design automation accord- ing to claim 1 further comprising, providing that every piece 
ing to claim 1 further comprising, enabling interaction with 40 of data or attribute of a design element in the Data Mao- 
said Managers of the DMS to perform tasks such as Auto- agement System (DMS), regardless of origin or importance, 
mated Library Processing, Problem Fix and EC is tracked by its PFVL single logical association of every 
management, BOM Tracking, Authority and Lock checking piece of the design. 

before, during and after the promotion of data in the DMS. 25. Amethod for computerized design automation accord- 

17. Amethod for computerized design automation accord- 45 ing to claim 1 wherein a database for the control repository 
ing to claim 1 further comprising, enabling the use of includes a multimedia database. 

Automated Library Machines in a client server environment 26. Amethod for computerized design automation accord- 
for purposes of processing promotion requests, initiating and ing to claim 1 wherein a database for the data repository 
executing Automated Library Processes, installing newly includes a multimedia database, 

created data into the DMS, performing any other functions 50 

provided by said Managers of the DMS, and permitting * • # * « 
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